Under ``special'' circumstances, the kernel support for ext2fs generates a filesystem that is corrupted, according to fsck.ext3. Systems: - FreeBSD myhost1 10.1-RELEASE-p6 FreeBSD 10.1-RELEASE-p6 #0: Tue Feb 24 19:00:21 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 - FreeBSD myhost2 9.3-STABLE FreeBSD 9.3-STABLE #111 r280132M: Mon Mar 16 10:02:12 CET 2015 root@myhost2:/usr/obj/usr/src/sys/GENERIC i386 Steps to reproduce: Create a dummy filesystem, extract a certain archive inside it, unmount it and fsck it. In steps: # dd if=/dev/zero of=disk.img bs=512M count=1 # mdconfig -a -t vnode -f disk.img # suppose it returns 'md0' # mkfs.ext3 /dev/md0 # mount -t ext2fs /dev/md0 /mnt # tar -C /mnt -xjf bugraising.tar.bz2 # umount /mnt/ # fsck.ext3 -f /dev/md0 e2fsck 1.42.12 (29-Aug-2014) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Directory inode 8262, block #1, offset 2020: directory corrupted Salvage<y>? The file 'bugraising.tar.bz2' contains private data; I would rather send it to individual e-mail addresses if you don't mind, instead of making it publicly available. It's only 1.2 megabytes. On 9-STABLE, it looks like there is a difference if I wait for some seconds between the 'tar' and 'umount' commands: the longer I wait, the more likely is the filesystem to be corrupted. The corruption of the filesystem is confirmed by a Linux system, on which the filesystem was initially to be used. After fixing the filesystem inconsistencies, it looks like that the ls -lR output remains the same; i.e. there is no visible difference in the file layout. Please tell me how and where can I send/submit the ``bug-raising'' archive, or if what I am doing is by any means unsupported.
Created attachment 154616 [details] Script that triggers the bug I wrote this script to check different combinations of image size, filesystem (ext2 vs ext3) and sleep time before unmount. On my 10.1-RELEASE-p6 system, these parameters trigger the bug: - size: 128 MB; - fs: ext2 (for mkfs and fsck); - sleep time: 1 second. When changing the size to 64 MB the problem seems to go away, but it's hard to deduce a precise law.
(In reply to Arrigo Marchiori from comment #1) Ciao Arrigo; Thank you for the report. There's no need to submit the tarball. Can you try disabling the "dir_index" feature (with e2tunefs) and try again? Thanks, Pedro.
(In reply to Pedro F. Giffuni from comment #2) Ciao Pedro! Thank you for your answer. It seems that clearing the "dir_index" feature makes the problem disappear! I tested it on the 10.1-release-p6 system using the ad-hoc tarball. I will try this setting tomorrow, on my 9-STABLE system, with the full ext2 filesystem on real hardware. I will keep you updated. Thank you again and have a nice Sunday.
Created attachment 154649 [details] Script that triggers the bug (2nd version: dir_index) Second version of the script. It allows to enable or disable the dir_index feature in the created filesystem.
(In reply to Arrigo Marchiori from comment #4) Thank you for you report and followup. I will be removing the dir_index feature altogether. It's an interesting ext3/4 -specific feature but it is not necessary, and we have two open bugs reports concerning it. Luckily version control works nicely and it can always be resurrected if we need it.
(In reply to Pedro F. Giffuni from comment #5) Ciao Pedro, I confirm that disabling the dir_index feature seems to solve the problem. Removing the feature also seems a good idea to me, if it is not a strict requirement for fs compatibility. On the other hand, in case you wish to investigate and debug the problem in the future, feel free to contact me if you think I can be of any help. I leave the choice to you, whether to mark this bug duplicate of bug #191895 or not. Thank you for your time.
Grab the issue. I will fix this (somewhat brutally).
A commit references this bug: Author: pfg Date: Fri Apr 17 22:26:04 UTC 2015 New revision: 281670 URL: https://svnweb.freebsd.org/changeset/base/281670 Log: Drop experimental dir_index support. The htree directory index is a highly desirable feature for research purposes and was meant to improve performance in our ext2/3 driver. Unfortunately our implementation has two problems: - It never really delivered any performance improvement. - It appears to corrupt the filesystem in undetermined circumstances. Strictly speaking dir_index is not required for read/write support in ext2/3 and our limited ext4 support still works fine without it. Regain stability in the ext2 driver by removing it. We may need it back (fixed) if we want to support encrypted ext4 support but thanks to the wonders of version control we can always revert this change and bring it back. PR: 191895 PR: 198731 PR: 199309 MFC after: 5 days Changes: head/sys/fs/ext2fs/ext2_dir.h head/sys/fs/ext2fs/ext2_extern.h head/sys/fs/ext2fs/ext2_hash.c head/sys/fs/ext2fs/ext2_htree.c head/sys/fs/ext2fs/ext2_lookup.c head/sys/fs/ext2fs/ext2_vfsops.c head/sys/fs/ext2fs/ext2fs.h head/sys/modules/ext2fs/Makefile
A commit references this bug: Author: pfg Date: Wed Apr 22 00:38:14 UTC 2015 New revision: 281841 URL: https://svnweb.freebsd.org/changeset/base/281841 Log: MFC r281670, r281703: Drop experimental ext2fs dir_index support. The htree directory index is a highly desirable feature for research purposes and was meant to improve performance in our ext2/3 driver. Unfortunately our implementation has two problems: - It never really delivered any performance improvement. - It appears to corrupt the filesystem in undetermined circumstances. Strictly speaking dir_index is not required for read/write support in ext2/3 and our limited ext4 support still works fine without it. Regain stability in the ext2 driver by removing it. We may need it back (fixed) if we want to support encrypted ext4 support but thanks to the wonders of version control we can always revert this change and bring it back. PR: 191895 PR: 198731 PR: 199309 Changes: _U stable/10/ stable/10/sys/conf/files stable/10/sys/fs/ext2fs/ext2_dir.h stable/10/sys/fs/ext2fs/ext2_extern.h stable/10/sys/fs/ext2fs/ext2_hash.c stable/10/sys/fs/ext2fs/ext2_htree.c stable/10/sys/fs/ext2fs/ext2_lookup.c stable/10/sys/fs/ext2fs/ext2_vfsops.c stable/10/sys/fs/ext2fs/ext2fs.h stable/10/sys/modules/ext2fs/Makefile
A commit references this bug: Author: pfg Date: Wed Apr 22 00:40:44 UTC 2015 New revision: 281842 URL: https://svnweb.freebsd.org/changeset/base/281842 Log: MFC r281670, r281703: Drop experimental ext2fs dir_index support. The htree directory index is a highly desirable feature for research purposes and was meant to improve performance in our ext2/3 driver. Unfortunately our implementation has two problems: - It never really delivered any performance improvement. - It appears to corrupt the filesystem in undetermined circumstances. Strictly speaking dir_index is not required for read/write support in ext2/3 and our limited ext4 support still works fine without it. Regain stability in the ext2 driver by removing it. We may need it back (fixed) if we want to support encrypted ext4 support but thanks to the wonders of version control we can always revert this change and bring it back. PR: 191895 PR: 198731 PR: 199309 Changes: _U stable/9/sys/ _U stable/9/sys/conf/ stable/9/sys/conf/files _U stable/9/sys/fs/ stable/9/sys/fs/ext2fs/ext2_dir.h stable/9/sys/fs/ext2fs/ext2_extern.h stable/9/sys/fs/ext2fs/ext2_hash.c stable/9/sys/fs/ext2fs/ext2_htree.c stable/9/sys/fs/ext2fs/ext2_lookup.c stable/9/sys/fs/ext2fs/ext2_vfsops.c stable/9/sys/fs/ext2fs/ext2fs.h _U stable/9/sys/modules/ stable/9/sys/modules/ext2fs/Makefile
Fixed for the next release. Thanks for reporting!
(In reply to Pedro F. Giffuni from comment #11) Thank you, Pedro, for taking care of this!