On Tue, Dec 04, 2012 at 05:11:37PM +0100, Bernd Schubert wrote: > I still don't know if it is related to htree only, but e2fsck isn't > properly fixing directory issues without the "-D" option. > For example I have a VM here, where the kernel frequently reports > something like: > > > [ 304.096059] EXT4-fs (vdb): error count: 4 > > [ 304.096305] EXT4-fs (vdb): initial error at 1352366631: htree_dirblock_to_tree:861: inode 3146582: block 1641814 > > [ 304.096857] EXT4-fs (vdb): last error at 1352381914: empty_dir:2334: inode 3146582: block 1641814 > > [86807.520052] EXT4-fs (vdb): error count: 4 > > and e2fsck does not report anything. This is not an error; this is pointing out that there previously *was* an error, with the first file system error happening at: % date --date "@1352366631" Thu Nov 8 04:23:51 EST 2012 and the most recent file system error happening at: % date --date "@1352381914" Thu Nov 8 08:38:34 EST 2012 (your results may differ depending on your local time zone :-) Newer versions of e2fsck clear this information from the superblock after the file system is successfully fixed. You upgraded your kernel without also updating e2fsprogs, and the newer kernels will print this message approximately once a day so that users who have their file systems set up to use errors=continue, that they get some warning that their file system has been corrupted, even if their log files have been rotated away. It's also useful when trying to debug user problems where they are convinced it is an ext4 bug, but in fact it's because they've buggered their init scripts not to run fsck, or they are using an external USB disk with ext4 and aren't bothering to check it with e2fsck after an error was reported, etc. We can now see that the file system had been first corrupted $N weeks/months ago, and it isn't a file system regression worthy of linkbait scares articles on some random website... In any case, that's why you're seeing it. It's really not a problem, only a cosmetic issue, which can be easily fixed by upgrading e2fsprogs. > Also the dir_entry_type is for some > dirs wrongly reported by the kernel, but seen correctly by e2fsck > (https://bugzilla.kernel.org/show_bug.cgi?id=50261). I've looked at your bug report, and it seems pretty clear that it's correct on disk. I'm not sure what might be going on, but this doesn't look like an e2fsck problem, but either a problem in glibc, the vfs kernel code or the ext4 kernel code. If you re-run your program, is it consistent which directories apparently have the wrong d_type information returned for them? > I hope to find some time to investigate that next week. I have seen it > several times already, but never had the chance to investigate or to > take an image. > > So I would really recommend to run "e2fsck -D" for the issue reported here. Did e2fsck -D really change what you saw? That will rewrite all of the directories as part of optimizing them all, but it certainly won't fix the error count/first error/last error series of informational messages. For that you just need to get a newer version of e2fsck. Regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html