From: "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
To: Duncan Sands <baldrick@wanadoo.fr>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
ext2-devel@lists.sourceforge.net, adilger@clusterfs.com
Subject: Re: Htree ate my hard drive, was: post-halloween 0.2
Date: Thu, 31 Oct 2002 13:19:23 +0200 [thread overview]
Message-ID: <62C20ED5AAC@vcnet.vc.cvut.cz> (raw)
On 31 Oct 02 at 9:20, Duncan Sands wrote:
> > I wonder if there is still a bug in the e2fsck code for re-hashing
> > directories? It shouldn't be possible to have e2fsck complete and
> > there still be an error in the filesystem (ok, sometimes it happens,
> > but in those cases it spews a lot of warnings about the filesystem
> > not being fixed yet and to run manually).
>
> It is possible that the filesystem was fine when fsck completed, but
> was damaged afterwards, i.e. in the time between fsck completing
> and the reboot.
Just stupid idea. Two or three months ago I complained that if
my box crashes shortly after boot, following things happen:
(1) system for some reason reads /var/run directory to page cache
(2) fsck finds that /var/run/* entries points to invalid nodes, and
removes them (through block device access)
(4) / is remounted read-write
(5) because of page cache for block device and directory is not
coherent (or what...), system still sees /var/run/* populated
(6) rm /var/run/* is run. FS is remounted read-only due to
freeing inode already freeed...
(7) Reboot, run fsck again, reboot, fine...
Nobody answered it at that time, and it happened at least 5 times
again to me - until I modified initscripts to do unconditional
reboot if "fsck /" did ANY modifications to filesystem.
Maybe kernel still uses old directory indexes structure after
fsck created new one?
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
next reply other threads:[~2002-10-31 12:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-31 11:19 Petr Vandrovec [this message]
2002-10-31 21:42 ` [Ext2-devel] Re: Htree ate my hard drive, was: post-halloween 0.2 chrisl
2002-10-31 22:03 ` Theodore Ts'o
-- strict thread matches above, loose matches on Subject: below --
2002-10-30 17:11 Dave Jones
2002-10-31 6:27 ` Htree ate my hard drive, was: " Duncan Sands
2002-10-31 8:07 ` Andreas Dilger
2002-10-31 8:20 ` Duncan Sands
2002-10-31 23:05 ` Mike Civil
2002-11-03 20:42 ` Duncan Sands
2002-11-03 22:00 ` Mike Civil
2002-11-03 22:11 ` Martin Waitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=62C20ED5AAC@vcnet.vc.cvut.cz \
--to=vandrove@vc.cvut.cz \
--cc=adilger@clusterfs.com \
--cc=baldrick@wanadoo.fr \
--cc=ext2-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.