Bug 141263 - dosfsck hangs while trying to repair corrupt full FAT32 file system
dosfsck hangs while trying to repair corrupt full FAT32 file system
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: dosfstools (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Ondrej Dvoracek
Ben Levenson
:
Depends On:
Blocks: 132991
  Show dependency treegraph
 
Reported: 2004-11-29 16:40 EST by J. Lewis Muir
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 15:12:55 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:41 EST, J. Lewis Muir
no flags Details

  None (edit)
Description J. Lewis Muir 2004-11-29 16:40:20 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 dosfsck to repair a corrupt full FAT32 file system, it consumes
100% of the CPU time and never exits.


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 never finishes:
   # dosfsck -v -V -a /dev/vg01/data
   dosfsck 2.8 (28 Feb 2001)
   dosfsck 2.8, 28 Feb 2001, FAT32, LFN
   Warning: FAT32 support is still ALPHA.
   Boot sector contents:
   System ID "mkdosfs"
   Media byte 0xf8 (hard disk)
          512 bytes per logical sector
        32768 bytes per cluster
           32 reserved sectors
   First FAT starts at byte 16384 (sector 32)
            2 FATs, 32 bit entries
     25641984 bytes per FAT (= 50082 sectors)
   Root directory start at cluster 2 (arbitrary size)
   Data area starts at byte 51300352 (sector 100196)
      6410466 data clusters (3899719680 bytes)
   128 sectors/track, 128 heads
            0 hidden sectors
    410370048 sectors total
   Starting check/repair pass.
   Reclaiming unconnected clusters.


Actual Results:  dosfsck consumes 100% of the CPU time and never exits.

Expected Results:  dosfsck should repair the file system and exit.

Additional info:

This only seems to happen for file systems that are somewhat large. For
a 130GB file system, dosfsck ran, taking up 100% of the CPU time, and
the disk showed no activity, but dosfsck did finally finish the repair
after 5-10 minutes.

But for a 196GB file system, dosfsck never finished after allowing it to
run for over 4 days (I gave up and interrupted it).
Comment 1 J. Lewis Muir 2004-11-29 16:41:31 EST
Created attachment 107577 [details]
Script used in step 7 to generate files
Comment 2 Peter Vrabec 2005-02-24 11:55:49 EST
I can't reproduce it.

How did u corrupt that filesystem?
I used 187GB filesystem, follow steps to reproduce and dosfsck -v -V -a
/dev/sda1 takes few seconds.
Comment 3 J. Lewis Muir 2005-03-02 11:51:27 EST
I corrupted it by following the steps. I created the FAT32 file system on an LVM logical volume.
Comment 4 Peter Vrabec 2005-03-07 08:53:49 EST
Which step is that corruption? 7?

How did U create FAT32 on LVM logical volume?

#sfdisk -l /dev/sda
 Disk /dev/sda: 24321 cylinders, 255 heads, 63 sectors/track
 Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 

    Device Boot Start     End   #cyls    #blocks   Id  System
 /dev/sda1          0+  24320   24321- 195358432   8e  Linux LVM
 /dev/sda2          0       -       0          0    0  Empty
 /dev/sda3          0       -       0          0    0  Empty
 /dev/sda4          0       -       0          0    0  Empty
# pvcreate /dev/sda1
  Physical volume "/dev/sda1" successfully created
# vgcreate vg01 /dev/sda1
  Volume group "vg01" successfully created
# lvcreate -L186.30G -ndata vg01
  Rounding up size to full physical extent 186.30 GB
  Logical volume "data" created
# dd if=/dev/zero of=/dev/vg01/data bs=512 count=1
 1+0 records in
 1+0 records out
# mkfs.vfat -F 32 -n TESTFS -v /dev/vg01/data
 mkfs.vfat 2.8 (28 Feb 2001)
 mkfs.vfat: unable to get drive geometry for '/dev/vg01/data'
Comment 5 J. Lewis Muir 2005-03-09 19:23:51 EST
I presume the corruption happens in step 7.

Making the FAT32 FS on the LVM LV works for me. Maybe LVM is confused
and a reboot would help to make creating the FAT32 FS work on your
computer?

Anyway, I just tried things on another computer and got the same
behavior that is reported in this bug report. Here's what I did.

I had an LVM logical volume at /dev/vg01/data that was originally
created from the RHEL installer at install time with an ext3 FS.

Then I unmounted the FS and did the following (the dosfsck ran for at
least 28 hours before I decided to kill it):
# dd if=/dev/zero of=/dev/vg01/data bs=512 count=1
1+0 records in
1+0 records out
# mkfs.vfat -F 32 -n TESTFS -v /dev/vg01/data
mkfs.vfat 2.8 (28 Feb 2001)
Selecting 64 sectors per cluster
/dev/vg01/data has 128 heads and 128 sectors per track,
logical sector size is 512,
using 0xf8 media descriptor, with 407642112 sectors;
file system has 2 32-bit FATs and 64 sectors per cluster.
FAT size is 49749 sectors, and provides 6367852 clusters.
Volume ID is 422ddc1e, volume label TESTFS     .
# mount -t vfat -o 'noatime,nodev,uid=502,gid=502,umask=007' /dev/vg01/data \
/data
# df -hl | grep 'Filesystem\|/dev/vg01/data'
Filesystem            Size  Used Avail Use% Mounted on
/dev/vg01/data        195G   32K  195G   1% /data
$ cd /data
$ ~/bin/make-test-data.sh 200
...
Creating data set 124:
...
  Creating image 73...FAILED
Failed to make image file: image-73.img
$ cd
# umount /data
# dosfsck -v -V -a /dev/vg01/data
dosfsck 2.8 (28 Feb 2001)
dosfsck 2.8, 28 Feb 2001, FAT32, LFN
Warning: FAT32 support is still ALPHA.
Boot sector contents:
System ID "mkdosfs"
Media byte 0xf8 (hard disk)
       512 bytes per logical sector
     32768 bytes per cluster
        32 reserved sectors
First FAT starts at byte 16384 (sector 32)
         2 FATs, 32 bit entries
  25471488 bytes per FAT (= 49749 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 50959360 (sector 99530)
   6367852 data clusters (2503344128 bytes)
128 sectors/track, 128 heads
         0 hidden sectors
 407642112 sectors total
Starting check/repair pass.
Reclaiming unconnected clusters.
Comment 6 RHEL Product and Program Management 2007-10-19 15:12:55 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

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