Date: Sun, 29 Apr 2012 10:37:40 +0200 From: Polytropon <freebsd@edvax.de> To: perryh@pluto.rain.com Cc: ait@p2ee.org, freebsd-questions@freebsd.org Subject: Re: UFS Crash and directories now missing Message-ID: <20120429103740.aa7df743.freebsd@edvax.de> In-Reply-To: <4f9ced3a.f7WBDlsMkhxvy%2BeF%perryh@pluto.rain.com> References: <201204281731.q3SHVaiM061997@mail.r-bonomi.com> <CAHieY7Tcv%2Bo-KbmLtPVHWXSphJX7b5f0QMO46yM-DOju4S9S7Q@mail.gmail.com> <20120428200116.b2f5820e.freebsd@edvax.de> <CAHieY7TpWsCbm8LZFMboWHgXJ2M79TbcK7Jse3=MoVUR2XB5Ow@mail.gmail.com> <4f9ced3a.f7WBDlsMkhxvy%2BeF%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 29 Apr 2012 00:26:50 -0700, perryh@pluto.rain.com wrote: > Alejandro Imass <ait@p2ee.org> wrote: > > > 3) the directories were moved at reboot by journal recovery, > > fsck or something else > > I think it's *extremely* unlikely that fsck was involved, because > it just doesn't do things like that. The point is: fsck moving directories "looks different". In case inodes get "de-connected" (their reference entries on level n-1 are gone, their data on level n is still present), fsck will access the lost+found/ directory in the corresponding partition's root directory (or create it, if not present) and write _new_ directory entries with the inode as their name, because that's the only naming information possible (as the original names on n-1 aren't accessible anymore). So those directories will have names like #177628676/ and they _can_ contain subtrees full of data, _including_ names from levels n+1 and onward. Files also are named #4767667892 and their names can _maybe_ identified from their content (the "file" command is helpful, and if they are textfiles containing a CVS or other revision control system data tag, it's possible to find out what they've been in their previous life). However, as it has been explained, fsck will _not_ do so unless being _allowed explicitely_ to do that kind of MODIFICATION to the file system. Flags like -yf can do that, but they are _not_ the default. This is due to the fact that _any_ critical modification of file systems requires the _responsible administrator_ to give permission. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120429103740.aa7df743.freebsd>