On Mon, 4 Nov 2002 22:42:13 +0000 Stephen C. Tweedie (SCT) wrote:
SCT> On Thu, Oct 31, 2002 at 01:07:17AM -0700, Andreas Dilger wrote:
SCT> > I wonder if there is still a bug in the e2fsck code for re-hashing
SCT> > directories?
SCT>
SCT> Possibly, but I'm more worried about why the fsck did a directory
SCT> optimise on reboot, especially on the root filesystem (where /dev is
SCT> usually stored). Doing major fs surgery on a mounted, readonly
SCT> filesystem is sort-of safe, but only if you reboot afterwards.
SCT> Continuing and remounting read-write can cause all sorts of damage as
SCT> the cached fs data no longer matches what's on disk.
Just a "me too". I've used htree with 2.5.44 and 2.4.20rc1. The next
fs check on the root filesystem founds corruption in /dev. After repairing
the damage and recreating the lost devices the machine ran ok for 2 days.
Then I had some ext3-fs errors and the partition got remounted read-only.
The following fsck revealed two inodes sharing the same block. I don't
have any logs of that incident anymore though :/
I'm running Slackware 9.0-beta and e2fsprogs-1.30-WIP.
Regards,
-Udo.
--=.Pg:IaKI3(A5HE+
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE9xwFUnhRzXSM7nSkRAopKAJ0ah2ZviPXPp6K0jRtm8TflYEBudwCdFX5U
V7satkwnAQ7lch3SjNGFqvo=
=qsGk
-----END PGP SIGNATURE-----
--=.Pg:IaKI3(A5HE+--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/