freebsd-skq/sys/fs
bde fb1dc96e72 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)
2007-07-10 13:20:24 +00:00
..
cd9660 Make insmntque() externally visibile and allow it to fail (e.g. during 2007-03-13 01:50:27 +00:00
coda Revert UF_OPENING workaround for CURRENT. 2007-05-31 11:51:53 +00:00
deadfs Below is slightly edited description of the LOR by Tor Egge: 2007-01-22 11:25:22 +00:00
devfs Since rev. 1.199 of sys/kern/kern_conf.c, the thread that calls 2007-07-03 17:42:37 +00:00
fdescfs Replace custom file descriptor array sleep lock constructed using a mutex 2007-04-04 09:11:34 +00:00
fifofs Revert UF_OPENING workaround for CURRENT. 2007-05-31 11:51:53 +00:00
hpfs Make insmntque() externally visibile and allow it to fail (e.g. during 2007-03-13 01:50:27 +00:00
msdosfs Don't use almost perfectly pessimal cluster allocation. Allocation 2007-07-10 13:20:24 +00:00
ntfs Make insmntque() externally visibile and allow it to fail (e.g. during 2007-03-13 01:50:27 +00:00
nullfs Where I previously removed calls to kdb_enter(), now remove include of 2007-05-29 11:28:28 +00:00
nwfs Change the VOP_OPEN(), vn_open() vnode operation and d_fdopen() cdev operation 2007-06-01 14:33:11 +00:00
portalfs Make insmntque() externally visibile and allow it to fail (e.g. during 2007-03-13 01:50:27 +00:00
procfs Eliminate now-unused SUSER_ALLOWJAIL arguments to priv_check_cred(); in 2007-06-12 00:12:01 +00:00
pseudofs Fix off-by-one error (introduced in r1.60) that had the effect of 2007-06-07 15:04:30 +00:00
smbfs Do proper "locking" for missing vmmeters part. 2007-06-04 21:45:18 +00:00
tmpfs MFp4: 2007-07-08 15:56:12 +00:00
udf Correct corrupt read when the read starts at a non-aligned offset. 2007-06-11 20:14:44 +00:00
unionfs Revert UF_OPENING workaround for CURRENT. 2007-05-31 11:51:53 +00:00