UFS Crash and directories now missing

[Robert Bonomi]

Alejandro Imass <aimass at yabarana.com> wrote:
> On Sat, Apr 28, 2012 at 11:39 AM, Robert Bonomi
> <bonomi at mail.r-bonomi.com> wrote:
> >  Alejandro Imass <aimass at yabarana.com> wrote:
> >> After a little more research, ___it it NOT unlikely at all___ that
> >> under high distress and a hard boot, UFS could have somehow corrupted
> >> the directory structure, whilst maintaining the data intact.
> >
> > This is techically accurate, *BUT* the specifics of the quote "corruption"
> > unquote in the case under discussion make it *EXTREMELY* unlikely that this
> > is what happened.
> >
> > 99.99+++% of all UFS filesystem "corruption' issues are the result of a
> > system crash _between_ the time cached 'meta-data' is updated in memory
> > and that data is flushed to disk (a deferred write).
> >
> > The second most common (and vanishingly rare) failure mode is a powerfail
> > _as_ a sector of disk is being written -- resulting in 'garbage data'
> > being written to disk.
> >
> > The next possibility is 'cosmic rays'.  If running on 'cheap' hardware 
> > (i.e., without 'ECC' memory), this can cause a *SINGLE-BIT* error in 
> > data being output.
> >
> > The fact that the 'corrupted' filesystem passed fsck -without- any reported
> > errors shows that everything in the filesystem meta-data was consistent
> >
> [...]
>
> > I think it is safe to conclude that the probabilities -greatly- favor
> > alternative #1.
> >
>
> OK. So after your comments and further research I concur with you on
> the mv but if it wasn't a human, then this might be exposing a serious
> security flaw in the jail system or the way EzJail implements it.

BOGON ALERT!!!   

Jails only prevent stuff -inside- the jail from affecting stuff outside the
jail.   They do *NOT* prevent stuff 'oustide the jail' from affecting stuff
INSIDE the jail.


"For any fool-proof system, there exists a *sufficiently*determined* fool
 capable of breaking it."

>                                                                   The
> whole point of using jails is to protect things like this from
> happening. 

FALSE TO FACT.

>            Given that the only jail that survived was the front-end
> Apache Web server/reverse proxy, then it is also safe to suspect the
> apache (or other) process running on it was able to perform a mv of
> the rest of the jails to it's own /usr/local/etc/apache22 directory.

FALSE TO FACT.

> Is there no possibility is that after the system crash, the journal
> recocery process and/or fsck could have moved this directories ?

"Anything is 'possible'" -- c.f. 'nasal monkeys'.

HOWEVER, if, for example, you would bother to examine the source code for 
fsck you would discover that it doesn't do -anything- 'significant' without
ASKING FIRST.   You reported it didn't find any problems -- not even anay
of the 'petty' ones it will correct w/o asking -if- the '-p' option is
specified.

"Journal revovery" _could_, 'theoretically' have done it -- *IF* "something 
else" did the 'mv' just before the crash, and that operation was journaled,
but not yet committed to disk at the time of the crash.  However, on a 
standard UFS filesystem, filesystem metadata updates are written 
'synchronously', which should eliminate _that_ wild, unfounded, speculaction.


 "You sir, don't know what you don't know, and much of what you "think" 
 you know is incorrect."