Red Hat Bugzilla – Bug 141275
Writing to FAT32 file system on USB hard drive locks up computer
Last modified: 2007-11-30 17:07:05 EST
Description of problem:
When I generate test files on a local file system and then use rsync to
copy those files to a FAT32 file system on a high-speed USB hard drive,
the computer locks up after transferring around 3-7GB worth of data
(sometimes less, sometimes more).
I can ping the computer but I can't log in at the console nor remotely
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Partition and format high-speed USB connected 250 GB hard drive
(these steps assume the USB hard drive is mapped to the /dev/sdb
device file) (perhaps a smaller hard drive will exhibit the same
# 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
# mkfs.vfat -F 32 -n EXTHD -v /dev/sdb1
2. # mkdir -p /mnt/exthd1
3. The UID and GID are that of the user 'jlmuir' that is used for
non-root commands indicated with a dollar sign prompt below. Of
course you will want to change the UID and GID to match your own.
# mount -t vfat -o 'noatime,nodev,uid=502,gid=502,umask=007' \
4. Make large scratch file system at /data (must be large enough to hold
generated data until writing to the USB hard drive causes the
computer to lock up - 10GB might be enough...or you might need more)
# mkdir /data/jlmuir
5. The punish-disk.tgz archive is included as an attachment to this bug
report. Extract punish-disk.tgz archive and edit bin/punish variables
PUNISH_DISK_HOME and EXT_HD_DEST to point to the correct location for
where you have extracted the archive and where you have mounted the
external USB hard drive. If you have used the paths shown in these
steps, no changes need to be made.
$ mkdir /mnt/exthd1/jlmuir
$ cd /data/jlmuir
$ tar -xpzvf ~/punish-disk.tgz
$ vi punish-disk/bin/punish
6. $ ./punish-disk/bin/punish
Actual Results: The punish script will stop printing progress output. It will not be
possible to log into the computer at the console nor remotely via SSH.
Expected Results: The punish script should run until either the local scratch file system
fills up or the external USB hard drive file system fills up. The script
should stop, and the computer should remain functional the entire time.
For all I know, this could be a problem with the kernel vfat driver
rather than the dosfstools.
The external hard drive is a LaCie d2 250 GB hard drive (model #
300718). It is connected via its USB interface and should be operating
in high-speed mode.
Here's model information about the USB controller I think is being used:
# lspci | grep -i usb
00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM \
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM \
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM \
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 \
EHCI Controller (rev 02)
Created attachment 107588 [details]
Scripts used for generating test files
I should also note that using this exact same hardware connected in
exactly the same way with an ext3 file system on the external hard drive
works fine. This made me think it was a problem solely with FAT32, but
then I tested this exact same hardware with a FAT32 file system on the
external hard drive connected via FireWire 400 instead of USB and it
worked fine. So it seems to be a problem with the pairing of USB and
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:
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.