Re: ext3 throughput woes on certain (possibly heavily fragmented) files
jw schultz (email@example.com)
Tue, 17 Sep 2002 14:55:40 -0700
On Mon, Sep 16, 2002 at 03:39:11PM -0700, Simon Kirby wrote:
> This box is primarily running a POP3 server (written in-house to cache
> mbox offsets, so that it can handle a huge volume of mail), and also
> exports the mail spool via NFS to other servers which run exim (-fsync).
> nfsd is exported async. Everything is mounted noatime, nodiratime. No
> applications should be calling sync/fsync/fdatasync or using O_SYNC.
> It's a mail server, so everything is fragmented.
> We're using dotlocking. Would this cause metadata journalling? We had
> to hash the mail spool a long time ago do to system time eating all CPU
> (the ext2 linear directory scan to find a slot available in the spool
> directory to add the dotlock file). I estimate about 200 - 300 dotlock
> files are created per second, but these should all be asynchronous.
> Would switching to fctnl() locking (if this works over NFS) solve the
I'd absolutly go to fcntl(). As bad as dotlocking is for
journaling filesystems it is even worse for NFS (when it works).
Look at the lkml thread "invalidate_inode_pages in 2.5.32/3"
to get an idea. Multiply the directory invalidations by the
size of the directories. fcntl() is the preferred way of locking
over NFS as it will even report if there is a problem with
J.W. Schultz Pegasystems Technologies
email address: firstname.lastname@example.org
Remember Cernan and Schmitt
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/