cvs commit: src/sys/fs/msdosfs msdosfs_fat.c msdosfsmount.h

Bruce Evans bde at FreeBSD.org
Tue Jul 10 13:20:25 UTC 2007


bde         2007-07-10 13:20:24 UTC

  FreeBSD src repository

  Modified files:
    sys/fs/msdosfs       msdosfs_fat.c msdosfsmount.h 
  Log:
  Don't use almost perfectly pessimal cluster allocation.  Allocation
  of the the first cluster in a file (and, if the allocation cannot be
  continued contiguously, for subsequent clusters in a file) was randomized
  in an attempt to leave space for contiguous allocation of subsequent
  clusters in each file when there are multiple writers.  This reduced
  internal fragmentation by a few percent, but it increased external
  fragmentation by up to a few thousand percent.
  
  Use simple sequential allocation instead.  Actually maintain the fsinfo
  sequence index for this.  The read and write of this index from/to
  disk still have many non-critical bugs, but we now write an index that
  has something to do with our allocations instead of being modified
  garbage.  If there is no fsinfo on the disk, then we maintain the index
  internally and don't go near the bugs for writing it.
  
  Allocating the first free cluster gives a layout that is almost as good
  (better in some cases), but takes too much CPU if the FAT is large and
  the first free cluster is not near the beginning.
  
  The effect of this change for untar and tar of a slightly reduced copy
  of /usr/src on a new file system was:
  
  Before (msdosfs 4K-clusters):
  untar:  459.57 real              untar from cached file (actually a pipe)
  tar:    342.50 real              tar from uncached tree to /dev/zero
  Before (ffs2 soft updates 4K-blocks 4K-frags)
  untar:   39.18 real
  tar:     29.94 real
  Before (ffs2 soft updates 16K-blocks 2K-frags)
  untar:   31.35 real
  tar:     18.30 real
  
  After (msdosfs 4K-clusters):
  untar    54.83 real
  tar      16.18 real
  
  All of these times can be improved further.
  
  With multiple concurrent writers or readers (especially readers), the
  improvement is smaller, but I couldn't find any case where it is
  negative.  342 seconds for tarring up about 342 MB on a ~47MB/S partition
  is just hard to unimprove on.  (This operation would take about 7.3
  seconds with reasonably localized allocation and perfect read-ahead.)
  However, for active file systems, 342 seconds is closer to normal than
  the 16+ seconds above or the 11 seconds with other changes (best I've
  measured -- won easily by msdosfs!).  E.g., my active /usr/src on ffs1
  is quite old and fragmented, so reading to prepare for the above
  benchmark takes about 6 times longer than reading back the fresh copies
  of it.
  
  Approved by:    re (kensmith)
  
  Revision  Changes    Path
  1.40      +4 -5      src/sys/fs/msdosfs/msdosfs_fat.c
  1.38      +1 -1      src/sys/fs/msdosfs/msdosfsmount.h


More information about the cvs-src mailing list