vol_id: does not recognise FAT* partitions with sector size 8192

Bug #147807 reported by Phil Richards
Affects Status Importance Assigned to Milestone
udev (Ubuntu)

Bug Description

Since upgrading from Edgy Eft to Feisty Fawn I have been unable to automount my external USB 250Gb SEAGATE harddrive.

I've been subscribed to a number of bugs on related problems, but not seen a solution. This weekend I tried Gutsy, and still no joy so I decided to dig deeper.
(I've posted some of the following to 102097, but I thought it might be clearer as a separate report.)

The problem boils down to vol_id not recognising the partition as VFAT. I've looked at the source code, and I think the problem is in
udev-113/extras/volume_id/lib/fat.c at around line 328:
 /* sector size check */
 sector_size = le16_to_cpu(vs->sector_size);
 if (sector_size != 0x200 && sector_size != 0x400 &&
     sector_size != 0x800 && sector_size != 0x1000)
  return -1;

Dumping out the header for the partition, I calculate that the sector_size on the partition is 0x2000 - which means that the partition is rejected on the FAT* checks.

Any chance of a fix? Pretty please?


description: updated
Changed in udev:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Kay: yet another vol_id bug

Revision history for this message
Kay Sievers (kaysievers) wrote :

The FAT spec says: "sector size must still be less than or equal to 4096".
Which tool did you use to format the volume?

Revision history for this message
Phil Richards (news-derived-software) wrote :

Well, the point was that *I* didn't format it. It came out of the box (from Seagate) formatted that way.

It's really a none issue for me now - I gave up and reformatted the disk with different filesystem types :-) (Something I would have done early, but moving 200 Gb of data around was slightly fiddly on my current machine).

However, I was slightly surprised that it worked with Edgy Eft (and had worked with my previous Gentoo install for quite a long time), and stopped working with Feisty Fawn - that's why I raised the issue. The fact that one manufacturer (who, it could be argued, should know better) is shipping disks with a "bogus" sector size is probably slightly worrying... on the other hand, they are shipping them, and users will plug them in and find that Linux doesn't see the disk whereas Windows does, and say "Linux doesn't recognise my hard disk". (vol_id is being safely paranoid, but I wonder if the check could be relaxed a little, regardless of what the spec says.) For what it's worth, blkid did report the information correctly.

Anyway, as I said, I have fixed the problem locally by other means, so it no longer affects me.


Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

"The maximum default cluster size under Windows XP is 4 kilobytes (KB) because NTFS file compression is not possible on drives with a larger allocation size. The Format utility never uses clusters that are larger than 4 KB unless you specifically override that default either by using the /A: option for command-line formatting or by specifying a larger cluster size in the Format dialog box in Disk Management. "
  -- http://support.microsoft.com/kb/314878

That also has the following table:

  Drive size
   (logical volume) FAT type Sectors Cluster size
       15 MB or less 12-bit 8 4 KB
       16 MB - 127 MB 16-bit 4 2 KB
      128 MB - 255 MB 16-bit 8 4 KB
      256 MB - 511 MB 16-bit 16 8 KB
      512 MB - 1,023 MB 16-bit 32 16 KB
    1,024 MB - 2,048 MB 16-bit 64 32 KB
    2,048 MB - 4,096 MB 16-bit 128 64 KB
   *4,096 MB - 8,192 MB 16-bit 256 128 KB Windows NT 4.0 only
   *8,192 MB - 16384 MB 16-bit 512 256 KB Windows NT 4.0 only

Also see:

"As versions of Windows NT earlier than 3.51 do not support NTFS file compression, the default cluster sizes will go above 4k."
  -- http://support.microsoft.com/kb/140365

So it seems that FAT itself goes up to 256KB sector sizes -- but that usually Windows prefers you to stay at 4KB or below.

vol_id should still probably support the larger sector sizes, especially if disk makers are formatting with them against Microsoft's recommendation.

Revision history for this message
Kay Sievers (kaysievers) wrote :

Sounds good, let's just add these values.

Revision history for this message
Kay Sievers (kaysievers) wrote :

Comitted a fix to the udev git tree.
I have no idea how a value of 256k fit into a 16bit value. :)

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

udev (117-1) hardy; urgency=low

  * New upstream release:
    - udev ancillary tools merged into a single udevadm binary.
    - dynamic rules may be created in /dev/.udev/rules.d
    - SYMLINK=="value" matches currently defined symlinks.
    - RUN{ignore_error} will ignore errors from programs.
    - vol_id recognises FAT partitions with 8192 sector size. LP: #147807.

  * debian/patches/10-git-linux_raid-1.0-metadata.patch:
    - Dropped, included in new upstream version.
  * debian/patches/80-extras-firmware.patch:
    - Change to add a new extra helper rather than patch the existing one,
      makes updating easier.

  * 00-init.rules:
    - Rename to 05-udev-early.rules to match upstream
  * 05-options.rules:
    - Do not remove static devices
  * 20-names.rules:
    - Update to 2.6.24-style usb_device objects
  * 40-permissions.rules:
    - Update to 2.6.24-style usb_device objects
    - Place SCSI type 4 devices into the cdrom group
  * 65-persistent-storage-tape.rules:
    - New upstream rules file for tape devices containing rules separated
      out from 65-persistent-storage.rules
  * 90-modprobe.rules:
    - Fix strange syntax error introduced by mjg59 leaving a note in the
      rule that wasn't in a comment.
  * 99-udevmonitor.rules:
    - Rename to 95-udev-late.rules to match upstream
    - Run REMOVE_CMD environment if it exists.

  * debian/migrate-iftab.pl:
    - Lowercase MAC addresses on migration. LP: #151786.
  * debian/udev.init:
    - Update all binaries to be calls to udevadm.
  * debian/udev.initramfs-hook:
    - Copy in udevadm rather than the symlinks to it.
    - Update filenames of early rules file.
    - Copy in late rules now we have udev monitor there.
  * debian/udev.initramfs-nfs:
    - Update all binaries to be calls to udevadm.
  * debian/udev.initramfs-premount:
    - Update all binaries to be calls to udevadm.
  * debian/udev.installer-startup:
    - Update all binaries to be calls to udevadm.

 -- Scott James Remnant <email address hidden> Fri, 14 Dec 2007 12:15:30 +0000

Changed in udev:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers