nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] some indexing results


From: Valdis . Kletnieks
Subject: Re: [Nmh-workers] some indexing results
Date: Tue, 15 Feb 2011 11:35:21 -0500

On Tue, 15 Feb 2011 16:12:42 GMT, Paul Vixie said:
> > From: address@hidden
> > Date: Tue, 15 Feb 2011 10:42:34 -0500
> > 
> > 00.21 versus 33.47?  I'd really investigate hot/cold cache effects
> > there.  If you "just" moved it to UFS, a copy is probably still in
> > cache.  Any way to flush the in-memory file cache on your box and
> > try again?
> 
> there isn't but freebsd only has one buffer, inode, and metadata cache,
> it's not per-filesystem.  and i ran those scans back to back, so if there
> are caching effects going on then the second and third scans ought to be
> equally fast for the two file systems.  it may be that rather than a
> fragmentation problem there's a VFS flagging problem where ZFS is advising
> the buffer cache not to keep copies of the metadata.  either way i'm going
> to take a look at geom/gvinum.  i don't mind a write penalty for raid6/raidz2
> but a read penalty of this many orders of magnitude is just too whacky.

Well, a quick look indicates that 00.21 can't *possibly* be off the disk
for 4,000+ files, unless you have a disk system that can return 20,000
inode reads for stat() calls per second (not counting all the *other*
I/O such as actually reading the file :)  Unfortunately, I understand
Linux innards better than FreeBSD, so you're on your own on this one. ;)

Attachment: pgpdfPu3n6e8h.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]