From: Dave Chinner <david@fromorbit.com>
To: karn@ka9q.net
Cc: xfs@oss.sgi.com
Subject: Re: realtime partition support?
Date: Sat, 8 Jan 2011 13:17:29 +1100 [thread overview]
Message-ID: <20110108021728.GA28803@dastard> (raw)
In-Reply-To: <4D2724E0.9020801@philkarn.net>
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@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-01-08 2:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-07 14:36 realtime partition support? Phil Karn
2011-01-08 2:17 ` Dave Chinner [this message]
2011-01-08 3:59 ` Phil Karn
2011-01-08 6:29 ` Stan Hoeppner
2011-01-08 14:42 ` Phil Karn
2011-01-10 0:35 ` Dave Chinner
2011-01-10 10:58 ` Phil Karn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110108021728.GA28803@dastard \
--to=david@fromorbit.com \
--cc=karn@ka9q.net \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox