Re: 2.4.20-rc3 ext3 fsck corruption -- tool update warning needed?

Theodore Ts'o (tytso@mit.edu)
Mon, 25 Nov 2002 22:55:56 -0500


On Mon, Nov 25, 2002 at 10:57:39AM +0000, Hugo Mills wrote:
> Running fsck recovers the missing files into lost+found, but
> doesn't remove the duplicated filenames.

E2fsck doesn't currently check for duplicated files in a directory.
It probably should, but doing so would increase its required memory
usuage and/or its run-time, at least in the non-HTREE case, which is
why I never implemented it. (Currently we scan all directory blocks
in the filesystem sorted by disk block number, to avoid seeks. So in
order to check for duplicates, we would either need to allocate enough
disk space to store all directory entries on the filesystem in memory
--- which would take up lost of memory --- or scan directory blocks
directory by directory, which would significantly increase the number
of seeks needed by e2fsck in its pass 2 processing.)

If the directory is indexed using the HTREE format, or the directories
are going to be optimized anyway by specifying the -D option in newer
versions e2fsck, adding support for detecting duplicate filenames
would be really cheap, so I'll very likely end up adding this feature
in an upcoming release of e2fsck.

Given the reports that people with xfs filesystems are also seeing
filesystem corruption, it sounds like filesystem blocks are getting
written to the wrong location on disk. That would explain the
duplicate filenames in the directory, as well as files disappearing.
In general this sort of corruption is relatively rare, which is
another reason why I havne't bothered with adding that support to
e2fsck.

- Ted
-
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/