Opened 13 years ago

Closed 12 years ago

#368 closed defect (fixed)

Free cluster summary wrong on FAT32

Reported by: Jakub Jermář Owned by: Jakub Jermář
Priority: major Milestone: 0.5.0
Component: helenos/fs/fat Version: mainline
Keywords: Cc:
Blocker for: Depends on:
See also:


As of mainline,1186, the following will leave a FAT32 file system in and unhealthy state as detected by the dosfsck utility.

  1. create and empty FAT32 file system using the Linux mkfs.msdos utility
  2. mount it from HelenOS
  3. in the mounted root, do this:
    # mkdir červený
    # cd červený
    # mkdir trpaslík
  4. unmount the file system in HelenOS
  5. run dosfsck -v on the image

In my case, dosfsck reports:

dosfsck 3.0.9 (31 Jan 2010)
dosfsck 3.0.9, 31 Jan 2010, 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
      4096 bytes per cluster
        32 reserved sectors
First FAT starts at byte 16384 (sector 32)
         2 FATs, 32 bit entries
   2617344 bytes per FAT (= 5112 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 5251072 (sector 10256)
    654078 data clusters (2679103488 bytes)
32 sectors/track, 64 heads
         0 hidden sectors
   5242880 sectors total
Checking for unused clusters.
Checking free cluster summary.
Free cluster summary wrong (654077 vs. really 654075)
1) Correct
2) Don't correct

Change History (1)

comment:1 by Jakub Jermář, 12 years ago

Resolution: fixed
Status: newclosed

This is because FAT32 defines a FAT32-specific FS info sector in which it caches some information, including the number of free clusters. Our FAT server did not pay attention to this structure so far and thus when the file system was created using an external mkfs.msdos utility and some clusters were allocated in HelenOS, the cached value would come out of sync with the real number of free clusters.

Fixed in mainline,1253. Note that we don't actually keep the number accurate, but, we always invalidate the counter on unmount. This is OK for HelenOS as HelenOS does not make any use of this cached value and other OSes should not become confused by the discrepancy.

Note: See TracTickets for help on using tickets.