Bug 141253 - Writing to full FAT32 file system corrupts it
Summary: Writing to full FAT32 file system corrupts it
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Peter Staubach
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-29 21:15 UTC by J. Lewis Muir
Modified: 2007-11-30 22:07 UTC (History)
5 users (show)

Clone Of:
Last Closed: 2006-04-12 19:33:50 UTC

Attachments (Terms of Use)
Script used in step 7 to generate files (1.23 KB, text/plain)
2004-11-29 21:18 UTC, J. Lewis Muir
no flags Details

Description J. Lewis Muir 2004-11-29 21:15:22 UTC
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):

How reproducible:

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' \
     /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
   # 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.

Additional info:

Comment 1 J. Lewis Muir 2004-11-29 21:18:54 UTC
Created attachment 107574 [details]
Script used in step 7 to generate files

Comment 3 Alexander Viro 2004-12-10 11:02:39 UTC
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...

Comment 4 J. Lewis Muir 2004-12-14 18:32:10 UTC
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.

Comment 8 Peter Staubach 2005-09-27 15:26:22 UTC
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?

Note You need to log in before you can comment on or make changes to this bug.