cvs commit: src/sys/fs/msdosfs msdosfs_vnops.c

[Bruce Evans]

On Fri, 20 Jul 2007, Alfred Perlstein wrote:

> * Bruce Evans <bde at FreeBSD.org> [070720 10:06] wrote:
>> bde         2007-07-20 17:06:57 UTC
>>
>>   FreeBSD src repository
>>
>>   Modified files:
>>     sys/fs/msdosfs       msdosfs_vnops.c
>>   Log:
>>   Implement vfs clustering for msdosfs.
> ...
>>   msdosfs is now only slightly slower than ffs with soft updates for
>>   writing and slightly faster for reading when both use their best block
>>   sizes.  Writing is slower for msdosfs because of more sync writes.
>>   Reading is faster for msdosfs because indirect blocks interfere with
>>   clustering in ffs.
>
> Very cool, is there any merit for modifying ffs to reallocblks for
> indirect blocks?  Or does that not apply?  Basically, attempt to
> keep indirect blocks closeby to either each other or possibly
> the direct blocks they reference?

I modified ffs_reallocblks_ufs1() to try to keep the first indirect
block contiguous between the last direct block and the first block
pointed to by the indirect block.  This gives about a 10% speedup for
reading back a fresh (but uncached) copy of most of most of /usr/src
in the non-soft-updates case.  10% is quite large because most files
in /usr/src are smaller than 192K so they don't have an indirect block.
This doesn't work for soft updates, apparently because soft updates
delays the allocation and uses the delay to allocate the data blocks
more perfectly contiguously.  When the data blocks are contiguous,
there is no space for the indirect block, and soft updates appararently
moves it very far away.  (Without any block reallocation, it tends to
get allocated close to the data blocks but not contiguously in them.)
The effect is even more noticeable for ffs2.

Times for copying and reading back most of /usr/src, with the target a
new file system (with an old file system, it is often impossible to
allocate blocks contiguously, and things are much slower):

% ffs-16384-02048-1:
% tarcp /f srcs:                 50.11 real         0.27 user         3.38 sys
% tar cf /dev/zero srcs:         14.10 real         0.22 user         0.82 sys
% ffs-16384-02048-2:
% tarcp /f srcs:                 43.66 real         0.29 user         3.40 sys
% tar cf /dev/zero srcs:         15.79 real         0.12 user         0.93 sys
% ffs-16384-02048-as-1:
% tarcp /f srcs:                 20.22 real         0.31 user         3.16 sys
% tar cf /dev/zero srcs:         14.24 real         0.15 user         0.91 sys
% ffs-16384-02048-as-2:
% tarcp /f srcs:                 20.11 real         0.23 user         3.31 sys
% tar cf /dev/zero srcs:         15.77 real         0.08 user         0.97 sys

1/2 = ffs1/2; ""/as/su = default/async/soft-updates.

Read-back is generally 10% slower for ffs2, I think just because I haven't
modified ffs_reallocblks_ufs2().

% ffs-16384-02048-su-1:
% tarcp /f srcs:                 33.38 real         0.23 user         3.39 sys
% tar cf /dev/zero srcs:         16.63 real         0.10 user         0.95 sys

Read-back is 17 % slower for ffs1 + soft-updates than for ffs1.

% ffs-16384-02048-su-2:
% tarcp /f srcs:                 31.35 real         0.26 user         3.40 sys
% tar cf /dev/zero srcs:         18.30 real         0.14 user         0.93 sys

Read-back is 28 % slower for ffs2 + soft-updates than for ffs1.

The fastest time I've seen for this benchmark (read-back) on the same
hardware is 11.36 seconds for msdosfs with 8K-blocks (11.58 seconds
for the committed version).  The drive cannot do it faster than 7.5
seconds.

Bruce