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):
Steps to Reproduce:
1. # dd if=/dev/zero of=/dev/vg01/data bs=512 count=1
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
# 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' \
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
# 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
simply by trying to write to it when it is full.
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
If reproducible, could the experiment with running the Window chkdsk
utility be performed, ala BZ 141388, please?