Date: Tue, 25 Nov 1997 18:33:34 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, tlambert@primenet.com Cc: fs@FreeBSD.ORG Subject: Re: ufs slowness Message-ID: <199711250733.SAA25843@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> >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 agree. Perhaps it's just ext2fs hanging on to directory blocks better. > >Maybe. I don't see how, though. It has its own little cache for bitmap and inode blocks. I would have thought that this was usually a pessimization, but perhaps it prevents thrashing in this particular test. >> >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 >> >> I actually used `cp -pR' from ext2fs to ufs. > >I think you'll find that this is the culprit. Don't think so. The directories are fairly small and should stay in a cache. >You should do an "ls -fF" in a couple of equivalent directories and >see the ordering of directories vs. files for thiose directories which >contain both. You should find that they aren't identical. cp -pR doesn't quite preserve the order. I would have thought it uses the order reaterned by readdir(). After copying from ext2fs to ffs using two tars in a pipe, ffs is exactly as slow as before, although I've disturbed the ffs partition a little by building a world in it (it grew from 53% full to 66% full). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711250733.SAA25843>