Re: XFS vs Elevators (was Re: [PATCH RFC] nilfs2: continuous snapshotting file system)

On Thu, Aug 21, 2008 at 04:04:18PM +1000, Dave Chinner wrote:

On Thu, Aug 21, 2008 at 03:15:08PM +1000, Dave Chinner wrote:

quoted

On Thu, Aug 21, 2008 at 05:46:00AM +0300, Szabolcs Szakacsits wrote:

quoted

On Thu, 21 Aug 2008, Dave Chinner wrote:
Everything is default.

  % rpm -qf =mkfs.xfs
  xfsprogs-2.9.8-7.1 

which, according to ftp://oss.sgi.com/projects/xfs/cmd_tars, is the 
latest stable mkfs.xfs. Its output is

meta-data=/dev/sda8              isize=256    agcount=4, agsize=1221440 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=4885760, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=4096   blocks=0, rtextents=0

Ok, I thought it might be the tiny log, but it didn't improve anything
here when increased the log size, or the log buffer size.

One thing I just found out - my old *laptop* is 4-5x faster than the
10krpm scsi disk behind an old cciss raid controller.  I'm wondering
if the long delays in dispatch is caused by an interaction with CTQ
but I can't change it on the cciss raid controllers. Are you using
ctq/ncq on your machine?  If so, can you reduce the depth to
something less than 4 and see what difference that makes?

Just to point out - this is not a new problem - I can reproduce
it on 2.6.24 as well as 2.6.26. Likewise, my laptop shows XFS
being faster than ext3 on both 2.6.24 and 2.6.26. So the difference
is something related to the disk subsystem on the server....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com