Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 28 Apr 2012 13:52:02 -0400
From:      Alejandro Imass <ait@p2ee.org>
To:        freebsd-questions@freebsd.org
Subject:   Re: UFS Crash and directories now missing
Message-ID:  <CAHieY7Tcv%2Bo-KbmLtPVHWXSphJX7b5f0QMO46yM-DOju4S9S7Q@mail.gmail.com>
In-Reply-To: <201204281731.q3SHVaiM061997@mail.r-bonomi.com>
References:  <201204281731.q3SHVaiM061997@mail.r-bonomi.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 28, 2012 at 1:31 PM, Robert Bonomi <bonomi@mail.r-bonomi.com> w=
rote:
>
> Alejandro Imass <aimass@yabarana.com> wrote:
>> On Sat, Apr 28, 2012 at 11:39 AM, Robert Bonomi
>> <bonomi@mail.r-bonomi.com> wrote:
>> > =A0Alejandro 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 "corrupt=
ion"
>> > 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 memor=
y
>> > and that data is flushed to disk (a deferred write).
>> >
>> > The second most common (and vanishingly rare) failure mode is a powerf=
ail
>> > _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' hardwa=
re
>> > (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 rep=
orted
>> > errors shows that everything in the filesystem meta-data was consisten=
t
>> >
>> [...]
>>
>> > 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!!!
>

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".



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHieY7Tcv%2Bo-KbmLtPVHWXSphJX7b5f0QMO46yM-DOju4S9S7Q>