Date: Sat, 21 Jul 2007 15:38:29 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Alfred Perlstein <alfred@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, Bruce Evans <bde@freebsd.org>, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/fs/msdosfs msdosfs_vnops.c Message-ID: <20070721145924.J38837@delplex.bde.org> In-Reply-To: <20070721021027.GG45894@elvis.mu.org> References: <200707201706.l6KH6vaQ000567@repoman.freebsd.org> <20070721021027.GG45894@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Jul 2007, Alfred Perlstein wrote: > * Bruce Evans <bde@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070721145924.J38837>