mount time

[Peter B]

Is it normal with a mount time of 44 seconds for a 250G FAT32 volume ..?

xxxxxxxxxxxxxxxx

CPU: Intel(R) Pentium(R) M processor 1600MHz (1594.84-MHz 686-class CPU)

umass0: <Sunplus Technology Inc. USB to Serial-ATA bridge, class 0/0, rev 2.00/ec.02, addr 2> on uhub3
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <ST925082 7AS > Fixed Direct Access SCSI-2 device 
da0: 40.000MB/s transfers
da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C)

time mount_msdosfs -o large /dev/da0s1 /m/u0
0.000u 3.583s 0:44.43 8.0%      10+1111k 59504+1io 0pf+0w

Filesystem    Size    Used   Avail Capacity  Mounted on
/dev/da0s1    232G     30G    202G    13%    /m/u0

find /m/u0 | wc -l
    2731

xxxxxxxxxxxxxxxx

The following might be worth mentioning in the manpage:

fs/msdosfs/msdosfs_vfsops.c
  /*
   * Forbid export requests if filesystem has
   * MSDOSFS_LARGEFS flag set.
   */

  .
  .

  /*
   * Experimental support for large MS-DOS filesystems.
   * WARNING: This uses at least 32 bytes of kernel memory (which is not
   * reclaimed until the FS is unmounted) for each file on disk to map
   * between the 32-bit inode numbers used by VFS and the 64-bit
   * pseudo-inode numbers used internally by msdosfs. This is only
   * safe to use in certain controlled situations (e.g. read-only FS
   * with less than 1 million files).
   * Since the mappings do not persist across unmounts (or reboots), these
   * filesystems are not suitable for exporting through NFS, or any other
   * application that requires fixed inode numbers.
   */

The 'large' option is not mentioned in the manpage:

   vfs_flagopt(mp->mnt_optnew, "large", &pmp->pm_flags, MSDOSFS_LARGEFS);

The threeshold between "normal" and large is defined as:
  http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/msdosfs/msdosfs_vfsops.c?rev=1.174.2.1.2.1;content-type=text%2Fplain
  if( pmp->pm_HugeSectors > 0xffffffff / 
                          (pmp->pm_BytesPerSec / sizeof(struct direntry)) + 1)

  And wich will in all cases with 512 bytes per sector result in:
    0xffffffff / (512/32) +1 = 268435456.9375 * 512 = ~128 * 2^30 = ~128 GB

xxxxxxxxxxxxxxxx

  Also is this option still experimental?, it's available as R/W in 7.1 so
  it might be of importance..
  Maybe an alternative method for inode mapping is to use the first cluster
  of each file as the "inode" number. This would give 512 bytes per file on
  a 2 TB volume.

xxxxxxxxxxxxxxxx

I would suggest the following is included into the mount_msdosfs(8) manpage:

  large
          Use special mapping to handle msdos filesystems larger than 128 GB.

For msdos filesystems larger than 128 GB it's neccessary to use the 'large'
mount option. This will use 32 bytes of kernel memory for each file and
is released when the filesystem is unmounted. This option also prohibits
export for networked filesystems like NFS due inconsistent inode mapping
between unmount and the next mount command.

   /Peter