Red Hat Bugzilla – Bug 141253
Writing to full FAT32 file system corrupts it
Last modified: 2007-11-30 17:07:05 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/125.5.5 (KHTML, like Gecko) Safari/125.11 Description of problem: If I use the dd command to write zero-filled 8MB files to a FAT32 file system until it fails because the file system is full, the file system becomes corrupt. It seems that the file system needs to be a certain size before this behavior shows up. I got the behavior to show up on a 130GB, 196GB, and 233GB file system. I could not reproduce this problem on a 5GB file system. Perhaps the magic point is 128GB. Version-Release number of selected component (if applicable): dosfstools-2.8-10 How reproducible: Always Steps to Reproduce: 1. # dd if=/dev/zero of=/dev/vg01/data bs=512 count=1 ---OR--- For a non-LVM file system taking up the entire /dev/sdb disk: # dd if=/dev/zero of=/dev/sdb bs=1024 count=1024 # sfdisk /dev/sdb <<EOF 0,,c EOF # dd if=/dev/zero of=/dev/sdb1 bs=512 count=1 2. # mkfs.vfat -F 32 -n TESTFS -v /dev/vg01/data 3. # mkdir /data 4. # mount -t vfat -o 'noatime,nodev,uid=502,gid=502,umask=007' \ /dev/vg01/data /data 5. # df -hl | grep '/dev/vg01/data' /dev/vg01/data 196G 32K 196G 1% /data 6. $ cd /data 7. The script is included as an attachment to this bug report. It runs and eventually stops when the file system becomes full. $ ~/bin/make-test-data.sh 200 8. # umount /data 9. dosfsck reports FS errors (Note: dosfsck also never exits when trying to repair the file system, but I have filed this as a separate bug report). # dosfsck -v -V /dev/vg01/data Actual Results: dosfsck reports FS errors even though the FS was cleanly unmounted. Expected Results: dosfsck should not find any FS errors. The FS should not become corrupt simply by trying to write to it when it is full. Additional info:
Created attachment 107574 [details] Script used in step 7 to generate files
Umm... Obvious question: what does Windows say when it runs into resulting fs? If their kernel or fsck analog (chkdsk?) get unhappy, we definitely have a kernel bug; if not - that's dosfsck alone. In any case, bzip2 -9 of the image in question (start with zeroed-out device, create a filesystem, run script, then bzip2 -9 the device contents) would make testing much easier...
It would take quite a while to zero the disk, rerun the test, and bzip2 the file system. I had an existing file system that was corrupt, and so I bzip2'ed that and ran the Windows chkdsk against that. I've put my comments for all of this on bug 141388 since this file system was not corrupted by trying to write to a full file system. If you would find it quite useful, then I could spend the time to give you what you want, but it would probably take about two hours of my time and about 24 hours of wall time.
Is this reproducible under RHEL-3 U5, which includes the changes for BZ, 141388? If reproducible, could the experiment with running the Window chkdsk utility be performed, ala BZ 141388, please?