Bug 141253 - Writing to full FAT32 file system corrupts it
Writing to full FAT32 file system corrupts it
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Peter Staubach
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-29 16:15 EST by J. Lewis Muir
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-12 15:33:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description J. Lewis Muir 2004-11-29 16:15:22 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:
Comment 1 J. Lewis Muir 2004-11-29 16:18:54 EST
Created attachment 107574 [details]
Script used in step 7 to generate files
Comment 3 Alexander Viro 2004-12-10 06:02:39 EST
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 13:32:10 EST
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 11:26:22 EDT
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.