From owner-freebsd-questions@FreeBSD.ORG Sat Apr 28 18:08:11 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6670B1065673 for ; Sat, 28 Apr 2012 18:08:11 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mx1.freebsd.org (Postfix) with ESMTP id 122268FC26 for ; Sat, 28 Apr 2012 18:08:11 +0000 (UTC) Received: from r56.edvax.de (port-92-195-62-131.dynamic.qsc.de [92.195.62.131]) by mx01.qsc.de (Postfix) with ESMTP id DD4123CC7F; Sat, 28 Apr 2012 20:01:17 +0200 (CEST) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id q3SI1G7K002673; Sat, 28 Apr 2012 20:01:16 +0200 (CEST) (envelope-from freebsd@edvax.de) Date: Sat, 28 Apr 2012 20:01:16 +0200 From: Polytropon To: Alejandro Imass Message-Id: <20120428200116.b2f5820e.freebsd@edvax.de> In-Reply-To: References: <201204281731.q3SHVaiM061997@mail.r-bonomi.com> Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 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 Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 18:08:11 -0000 On Sat, 28 Apr 2012 13:52:02 -0400, Alejandro Imass wrote: > On Sat, Apr 28, 2012 at 1:31 PM, Robert Bonomi = wrote: > > > > Alejandro Imass wrote: > >> On Sat, Apr 28, 2012 at 11:39 AM, Robert Bonomi > >> wrote: > >> > =A0Alejandro 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 corrupt= ed > >> >> the directory structure, whilst maintaining the data intact. > >> > > >> > This is techically accurate, *BUT* the specifics of the quote "corru= ption" > >> > unquote in the case under discussion make it *EXTREMELY* unlikely th= at this > >> > is what happened. > >> > > >> > 99.99+++% of all UFS filesystem "corruption' issues are the result o= f a > >> > system crash _between_ the time cached 'meta-data' is updated in mem= ory > >> > and that data is flushed to disk (a deferred write). > >> > > >> > The second most common (and vanishingly rare) failure mode is a powe= rfail > >> > _as_ a sector of disk is being written -- resulting in 'garbage data' > >> > being written to disk. > >> > > >> > The next possibility is 'cosmic rays'. =A0If running on 'cheap' hard= ware > >> > (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 r= eported > >> > errors shows that everything in the filesystem meta-data was consist= ent > >> > > >> [...] > >> > >> > 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!!! > > >=20 > I admit my ignorance on how the filesystem works but I don't think > your condescending remarks add a lot of value. The issue here is this > actually happened and there is a flaw somewhere other than "the stupid > administrator did it". If you search the archives of this list, you'll find my _first_ post to that list: I've had a similar problem, df shows data must be there after crash (panic -> reboot -> fsck trouble), but files aren't there (even _not_ in lost+found). It's quite possible that in _exceptional_ moments this can happen. The fsck program is intended to repair the most typical file system faults, but nothing "complicated" will be done without interaction: Altering data on disk will _always_ involve the responsible (!) admin to check if it is really intended "to do so". There can be many reasons. I've never found out what was the reason for the trouble I've had. Some years ago, I found a "make" failing because "/uss/src/blah... something not found", and a quick memtest revealed the secret: defective RAM module that caused a "bit error", and the difference between "r" and "s" is just one bit. Replaced the module - everything worked. Mean soldering rays from outer space. :-) You'll find many useful forensic tools in the ports collection that might help locate "lost" data (quotes intended as long as the data is still on the disk). The more complex your setting is (e. g. striped disks, or ZFS), this can be nearly impossible. "Plain old UFS" can sometimes be your saviour (but BACKUP should be your real friend). --=20 Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...