xfs
[Top] [All Lists]

Re: PARTIAL TAKE 964999 - lazy superblock counters for XFS

To: Andi Kleen <andi@xxxxxxxxxxxxxx>
Subject: Re: PARTIAL TAKE 964999 - lazy superblock counters for XFS
From: David Chinner <dgc@xxxxxxx>
Date: Fri, 25 May 2007 09:24:05 +1000
Cc: David Chinner <dgc@xxxxxxx>, xfs@xxxxxxxxxxx, sgi.bugs.xfs@xxxxxxxxxxxx
In-reply-to: <p73wsyxdhb3.fsf@xxxxxxxxxxxxxx>
References: <20070522075932.E665058CA531@xxxxxxxxxxxxxxxxxxxxxxx> <p73wsyxdhb3.fsf@xxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
On Thu, May 24, 2007 at 11:48:16PM +0200, Andi Kleen wrote:
> dgc@xxxxxxx (David Chinner) writes:
> > 
> > The key to removing the contention is to not require the superblock
> > fields in question to be locked. We do that by not marking the
> > superblock dirty in the transaction. IOWs, we modify the incore
> > superblock but do not modify the cached superblock buffer. In short,
> > we do not log superblock modifications to critical fields in the
> > superblock on every transaction. In fact we only do it just before
> > we write the superblock to disk every sync period or just before
> > unmount.
> 
> Does this mean it will increases performance on small systems too
> due to less super block writes or is it purely for large
> system scalability?

If you are running 100 concurrent transactions to your small
filesystem, then yest, it will also help. But that sort of load
is usually seen on file servers  or large compute boxes doing lots
of file manipuations....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group


<Prev in Thread] Current Thread [Next in Thread>