Re: realtime partition support?

[Dave Chinner <david@fromorbit.com>]

On Fri, Jan 07, 2011 at 07:59:27PM -0800, Phil Karn wrote:
> On 1/7/11 6:17 PM, Dave Chinner wrote:
> >> Throughput on large files would be almost as fast as if everything were
> >> on the SSD.
> > 
> > Not at all. The data is still written to the rotating disk, so
> > the presence of the SSD won't change throughput rates at all.
> 
> My point is that the big win of the SSD comes from its lack of
> rotational and seek latency. They really shine on random small reads. On
> large sequential reads and writes, modern rotating disks can shovel data
> almost as quickly as an SSD once the head is in the right place and the
> data has started flowing. But it can't get there until it has walked the
> directory tree, read the inode for the file in question and finally
> seeked to the file's first extent.

Which often does not require IO because the path and inodes are
cached in memory.

> If all that meta information resided
> on SSD, the conventional drive could get to that first extent that much
> more quickly.

Not that much more quickly, because XFS uses readahead to hide a lot
of the directory traversal IO latency when it is not cached....

> > I'd also expect it to be be much, much slower than just using the
> > rotating disk for the standard data device - the SSD will make no
> > difference as metadata IO is not the limiting factor.
> 
> No? I'm having a very hard time getting XFS on rotating SATA drives to
> come close to Reiser or ext4 when extracting a large tarball (e.g., the
> Linux source tree) or when doing rm -rf. I've improved it by playing
> with logbsize and logbufs but Reiser is still much faster, especially at
> rm -rf. The only way I've managed to get XFS close is by essentially
> disabling journaling altogether, which I don't want to do. I've tried
> building XFS with an external journal and giving it a loopback device
> connected to a file in /tmp. Then it's plenty fast. But unsafe.

As has already been suggested, "-o delaylog" is the solution to that
problem.

> Turning off the write barrier also speeds things up considerably, but
> that also makes me nervous. My system doesn't have a RAID controller
> with a nonvolatile cache but it is plugged into a UPS (actually a large
> solar power system with a battery bank) so unexpected loss of power is
> unlikely. Can I safely turn off the barrier?

Should be safe.  In 2.6.37 the overhead of barriers is greatly
reduced. IIRC, on most modern hardware they will most likely be
unnoticable, so disabling them is probably not necessary...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs