From owner-freebsd-questions@FreeBSD.ORG Sat Apr 28 17:30:47 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D325106566B for ; Sat, 28 Apr 2012 17:30:47 +0000 (UTC) (envelope-from bonomi@mail.r-bonomi.com) Received: from mail.r-bonomi.com (mx-out.r-bonomi.com [204.87.227.120]) by mx1.freebsd.org (Postfix) with ESMTP id D65B58FC18 for ; Sat, 28 Apr 2012 17:30:46 +0000 (UTC) Received: (from bonomi@localhost) by mail.r-bonomi.com (8.14.4/rdb1) id q3SHVaiM061997 for freebsd-questions@freebsd.org; Sat, 28 Apr 2012 12:31:36 -0500 (CDT) Date: Sat, 28 Apr 2012 12:31:36 -0500 (CDT) From: Robert Bonomi Message-Id: <201204281731.q3SHVaiM061997@mail.r-bonomi.com> To: freebsd-questions@freebsd.org Subject: Re: UFS Crash and directories now missing X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 17:30:47 -0000 Alejandro Imass wrote: > On Sat, Apr 28, 2012 at 11:39 AM, Robert Bonomi > wrote: > > Alejandro Imass 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."