linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Torsten Scheck <torsten.scheck@gmx.de>
To: linux-kernel@vger.kernel.org
Subject: Large-FAT32-Filesystem Bug
Date: Fri, 05 Dec 2003 10:52:31 +0100	[thread overview]
Message-ID: <3FD0555F.5060608@gmx.de> (raw)

Dear friends:

I already sent a message to the VFAT maintainer, but I decided
to additionally bother this list with a warning. This way some
readers might avoid data loss.


I found a critical FAT32 bug when I tried to store data onto an
internal IDE 160 GB and onto an external USB2/FW-250 GB hard
disk.

 From a certain fill level on, the data clusters of a newly added
file entry get lost after a remount of the filesystem: the
directory entry of the file has the size 0, the data is lost, and
a fsck.vfat -r is needed to remove the unused clusters.

This happens to files residing in newly created directories.
Existing directories (e.g. the root directory) keep the data.  So
directories created after the fill level is reached, seem to be
unable to handle data clusters of file entries correctly.

With my 157 GB FAT32 partition the threshold is here:
/dev/hda2            157071104 135913952  21157152  87% /mnt/hda2

I reproduced the problem with two computers: a notebook with
Debian Testing and Linux Kernel 2.4.22, and a desktop computer
running Knoppix and the latest stable Kernel (2.4.23 #1 SMP Mi
Dez 3 12:46:35 CET 2003 i686 GNU/Linux).


With big external hard disks becoming very popular for data
exchange, I rely on FAT32 filesystems to be able to share data
with MS-Windows users. Within the next months many others might
reach the threshold and encounter data loss, too.  Therefore I
call this bug critical.

See transcript below for details about how to reproduce the bug.

All the best-
Torsten Scheck

------------8<------------8<------------8<------------8<----

# mkfs.vfat -F 32 /dev/hda2
mkfs.vfat 2.10 (22 Sep 2003)

# mount /mnt/hda2/

$ mount
/dev/hda2 on /mnt/hda2 type vfat (rw,umask=000)

$ cd /mnt/hda2

$ df .
/dev/hda2            157071104        16 157071088   1% /mnt/hda2

$ mkdir bigfiles
$ for (( i=1 ; i<=140 ; i++ )) ; do \
   dd if=/dev/zero of=bigfiles/f$i bs=1M count=1024; \
done

$ mkdir testfolder

$ echo "123456" > testfolder/testfile

$ ls -l testfolder/testfile
-rwxrwxrwx    1 t        t               7 2003-12-03 17:03
testfolder/testfile

$ cd

# umount /mnt/hda2

# mount /mnt/hda2

$ ls -l /mnt/hda2/testfolder/testfile
-rwxrwxrwx    1 t        t               0 2003-12-03 17:03
/mnt/hda2/testfolder/testfile

# umount /mnt/hda2

# fsck.vfat -vr /dev/hda2
dosfsck 2.10 (22 Sep 2003)
dosfsck 2.10, 22 Sep 2003, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "mkdosfs"
Media byte 0xf8 (hard disk)
        512 bytes per logical sector
      16384 bytes per cluster
         32 reserved sectors
First FAT starts at byte 16384 (sector 32)
          2 FATs, 32 bit entries
   39267840 bytes per FAT (= 76695 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 78552064 (sector 153422)
    9816944 data clusters (160840810496 bytes)
63 sectors/track, 255 heads
          0 hidden sectors
  314295660 sectors total
Checking for unused clusters.
Reclaimed 1 unused cluster (16384 bytes).
Checking free cluster summary.
Free cluster summary wrong (641900 vs. really 641901)
1) Correct
2) Don't correct
? 1
Perform changes ? (y/n) y
/dev/hda2: 143 files, 9175043/9816944 clusters
------------8<------------8<------------8<------------8<----


             reply	other threads:[~2003-12-05  9:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-05  9:52 Torsten Scheck [this message]
2003-12-05 13:17 ` Large-FAT32-Filesystem Bug jdow
2003-12-07 12:26   ` Helge Hafting
2003-12-07 12:20     ` Tomasz Torcz
2003-12-08  9:54       ` Helge Hafting
2003-12-08 14:10         ` Gene Heskett
2003-12-08 16:19           ` Randy.Dunlap
2003-12-07 13:56     ` Gene Heskett
2003-12-05 15:26 ` Eduard Bloch
2003-12-05 16:07 ` Erik Andersen
2003-12-05 17:54   ` Torsten Scheck
2003-12-05 22:10     ` Erik Andersen
2003-12-05 22:45       ` Mike Fedyk
2003-12-05 23:26         ` Måns Rullgård
2003-12-06  0:04           ` Andreas Schwab
2003-12-06  0:44             ` Måns Rullgård
2003-12-06  1:10               ` Andreas Schwab
2004-02-06 14:43   ` Torsten Scheck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3FD0555F.5060608@gmx.de \
    --to=torsten.scheck@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).