Re: Strange case of filesystem corruption?

From: Robert Watson (rwatson_at_FreeBSD.org)
Date: 09/06/05

  • Next message: Erik Norgaard: "solved: removing file '-D'" 
    Date: Tue, 6 Sep 2005 11:51:02 +0100 (BST)
To: Mikhail Teterin <mi+kde@aldan.algebra.com>

    On Mon, 5 Sep 2005, Mikhail Teterin wrote:

    > Can this be explained by anything other than a (nasty) bug?
    >
    > % ls -la audio/shorten/files
    > total 0
    > % rmdir audio/shorten/files
    > rmdir: audio/shorten/files: Directory not empty
    >
    > This is on 5.4-stable from July 21 -- up ever since... Thanks!

    Mikhail,

    Have you recently experienced a system crash or hard reboot without proper
    shutdown? I know of at least one case prior to 6.x where this can occur
    -- a bug I reported to Kirk relating to bgfsck. Basically, soft update
    guarantees that upon reboot after failure (power or otherwise), the
    on-disk layout of UFS meta-data will be consistent, except with respect to
    reference and link counts, which may be elevated. What bgfsck does is
    walk the file system to identify and correct the elevated counts. Here's
    a specific example of such a problem:

       Directory A is created
             Write A directory data (., ..)
             Write A directory inode (new inode)
             Write A parent inode (link count++)
             Write A parent data (add name)
       Directory B is created
             Write B directory data (., ..)
             Write B directory inode (new inode)
             Write A directory inode (link count++)
             XXX
             Write A directory data (add name)
       Directory B is removed
             Write A directory data (remove name)
             XXX
             Write A directory inode (link count--)

    Note that if the sequence of events his halted at either of the XXX's
    above, the inode link count on directory A will be elevated, even though
    the name for B has been removed from A. Background fsck comes alone
    later, notices that the counts are elevated, and drops them. However,
    until ufs_vnops.c:1.269, this caused a problem: because the link count was
    elevated, UFS assumed that the directory contained a reference to another
    directory, and would not let it be removed. Once bgfsck catches up with
    the directory, it can be removed.

    I've seen this symptom most frequently following a crash or a power outage
    during an rm -Rf of a /usr/obj, which I then immediately restart on
    reboot, and rm -Rf gets there before bgfsck does. Here's the commit
    message for ufs_vnops.c:1.269, which should be MFC'd:

       revision 1.269
       date: 2005/05/18 22:18:21; author: mckusick; state: Exp; lines: +2 -3
       Allow removal of empty directories with high link counts. These can
       occur on a filesystem running with soft updates after a crash and
       before a background fsck has been run. To prevent discrepancies
       from arising in a background fsck that may already be running,
       the directory is removed but its inode is not freed and is left
       with the residual reference count. When encountered by the
       background fsck it will be reclaimed.

    I'll e-mail Kirk and ask if he's comfortable enough with the change to
    this point to merge it.

    Robert N M Watson
    _______________________________________________
    freebsd-questions@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"

  • Next message: Erik Norgaard: "solved: removing file '-D'"

    Relevant Pages

    • Re: panic: handle_written_inodeblock: live inodedep
      ... > reboot from a crash, while background fsck was running: ... > Error while reading shared library symbols: ...
      (freebsd-current)
    • Re: swap and /tmp
      ... SuSE system because it insisted on downloading initially to /tmp ... It isn't obvious to me why these and any other repositories of volatile ... reboot on /var/run but it does not clearly says if directories may be ... If you have a crash with a partition based /tmp, ...
      (Debian-User)
    • Re: error C00D11BB
      ... I used Event Viewer to find the info below about the crash: ... The computer has rebooted from a bugcheck. ... >> over the screen followed by computer crash, shutdown and reboot. ...
      (microsoft.public.windowsmedia.player)
    • Re: Vista Blue Screen Crash while accessing the properties of a file
      ... Reboot and locate the System Volume Information folder and delete it. ... "Kevin Baykr" wrote in message ... then tried going to Previous Versions again, Blue Screen crash.. ... I also tried updating my Drivers, ...
      (microsoft.public.windows.vista.general)
    • Re: Vista Blue Screen Crash while accessing the properties of a file
      ... Hard to tell if they are related, aspi32.sys is an adaptec file used as a storage cable controller driver. ... Windows help - www.rickrogers.org ... In the event viewer the crash dump initialization again fail and on ... Ok, first stop the vss service, disable it and reboot. ...
      (microsoft.public.windows.vista.general)