Date: Sat, 28 Apr 2012 12:31:36 -0500 (CDT) From: Robert Bonomi <bonomi@mail.r-bonomi.com> To: freebsd-questions@freebsd.org Subject: Re: UFS Crash and directories now missing Message-ID: <201204281731.q3SHVaiM061997@mail.r-bonomi.com>
next in thread | raw e-mail | index | archive | help
Alejandro Imass <aimass@yabarana.com> wrote: > On Sat, Apr 28, 2012 at 11:39 AM, Robert Bonomi > <bonomi@mail.r-bonomi.com> wrote: > > Alejandro Imass <aimass@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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201204281731.q3SHVaiM061997>