xfs
[Top] [All Lists]

Re: realtime partition support?

To: karn@xxxxxxxx
Subject: Re: realtime partition support?
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sat, 8 Jan 2011 13:17:29 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <4D2724E0.9020801@xxxxxxxxxxxx>
References: <4D2724E0.9020801@xxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Fri, Jan 07, 2011 at 06:36:16AM -0800, Phil Karn wrote:
> What's the status of the realtime partition feature in XFS? I think I
> read somewhere that it wasn't actually implemented and/or working in the
> Linux XFS implementation, but I'm not sure. If it is in Linux, how well
> tested is it?

Experimental, implemented in linux and mostly just works, but is
largely untested and not really recommended for any sort of
production use.

> It occurred to me that the XFS realtime feature might be a quick and
> easy way to make a hybrid of a SSD and a rotating drive. Just create a
> XFS file system on the SSD that specifies the rotating drive as its
> realtime partition. This would put all the metadata on the SSD where it
> can be quickly accessed at random.

Has a couple of drawbacks: realtime device extent allocation is single
threaded, and it's not designed as a general purpose allocator.

> 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. In
fact, the rt device is not aimed at maximising throughput - it
was designed for deterministic performance for low-latency multiple
stream access patterns - so it will probably give lower throughput
than just using the rotating drive alone....

> Small files wouldn't be as fast, but still much faster than
> with no SSD at all.

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.  Further, the
rt allocator is simply not designed to handle lots of small files
efficiently so will trigger many more seeks for small file data IO
than the standard allocator (and hence be slower) because the
standard allocator packs small files tightly together...

It's a nice idea, but it doesn't really work out in practise
with the current XFS structure.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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