Date: Mon, 24 Nov 1997 18:39:42 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bde@zeta.org.au (Bruce Evans) Cc: fs@FreeBSD.ORG Subject: Re: ufs slowness Message-ID: <199711241839.LAA12388@usr01.primenet.com> In-Reply-To: <199711241014.VAA09419@godzilla.zeta.org.au> from "Bruce Evans" at Nov 24, 97 09:14:21 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> ffs (with a block size of 8K and a frag size of 1K) seems to be about > twice as slow as ext2fs (with a block size of 4K and a frag size of 4K) > for reading small files. This seems to be due to ffs doing lots more > seeks. E.g., for `tar cf /dev/null linux-2.1.63' where there are about > 50MB of files in the directory, ffs takes about 40 seconds and ext2fs > takes about 20 seconds. The extfs partition is on faster tracks but > is fuller. Typical output from systat: > > ext2fs ffs > seeks 372 144 > xfers 372 145 > blks 2751 1395 > msps 0.5 4.1 > > This was on an IDE so `msps' may actually be right (though it may be broken > for dma mode). All file systems were mounted async,noatime. 2.5MB/sec > exploits about half the disk bandwidth. Well, there's a lot of reasons that this would be true: o As you say, the ext2fs is on faster tracks. This is probably not hugely significant. o Is this a ZBR disk? If not, are you using FreeBSD's default settings, which pessimize geometry optimizations for these disks? o Was the FFS optimizing for space or time when writing? o Did you set a reasonable reserve so the hash-to-disk was efficient on the FFS writes, or did you take FreeBSD's politically motivated defaults (Hey! I'm "wasting" almost 1G of my 9G disk!). o ext2fs is extent based, so it's probably not dealing with indirect blocks. o You are engaging in an atypical usage pattern by doing a "tar" as your test. First, there is zero locality of reference, and second, the way tar traverses means that on a tree that large, you've effectively disable the name cache for FFS (you've damaged it for ext2fs as well, but not to the same degree of fairness, given the relative costs of directory operations and ext2fs's use of extent based files for storing directory data). I'd say the *vast* majority of time spent is in directory operations, rather than actual file data reading (ie: I think the hit from going to indirect blocks in FFS is small). I'm also betting that you created the ext2fs by tarring up the FFS and untarring it onto the ext2fs. Do the same to recreate an FFS on the same fast tracks, and I'll bet you see the performance gap narrow significantly (ie: creation order is important for files vs. directories in preterbing the tar traversal). Now I'm not arguing that an FS shouldn't be using a btree for its directory structure or anything like that 8-). But I think the particular test (a "tar race") isn't quite a fair comparison. There are a lot of ways to "put in the fix" on such a race without intending to do so. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711241839.LAA12388>