From: Dave Chinner <david@fromorbit.com>
To: Peter Grandi <pg_xf2@xf2.to.sabi.co.UK>
Cc: Linux fs XFS <xfs@oss.sgi.com>
Subject: Re: File system remain unresponsive until the system is rebooted.
Date: Thu, 2 Feb 2012 10:55:01 +1100 [thread overview]
Message-ID: <20120201235501.GX9090@dastard> (raw)
In-Reply-To: <20265.9379.139218.148520@tree.ty.sabi.co.UK>
On Wed, Feb 01, 2012 at 11:40:19AM +0000, Peter Grandi wrote:
> [ ... ]
>
> >>> We are using Amazon EC2 instances.
>
> >>> [ ... ] one of the the worst possible platforms for XFS.
>
> >> I don't agree with you there. If the workload works best on
> >> XFs, it doesn't matter what the underlying storage device is.
> >> e.g. if it's a fsync heavy workload, it will still perform
> >> better on XFS on EC2 than btrfs on EC2...
>
> There are special cases, but «fsync heavy» is a bit of bad
> example.
It's actually a really good example of where XFS will be better
than other filesystems. Why? Because XFS does less log IO due to
aggregation of log writes during concurrent fsyncs. The more latency
there is on a log write, the more aggregation that occurs. On a
platform where the IO subsystem is going to give you unpredictable
IO latencies, that's exactly what want.
Sure, it was designed to optimise spinning rust performance, but
that same design is also optimal for virtual devices with
unpredictable IO latency...
> In general file system designs are not at all independent of the
> expected storage platform, and some designs are far better than
> others for specific storage platforms, and viceversa.
Sure, but filesystems also have inherent capabilities that are
independent of the underlying storage. In these cases, the
underlying storage really doesn't matter if the filesystem can't do
what the application needs. Allocation parallelism, CPU
parallelism, minimal concurrent fsync latency, etc are all
characteristics of filesystems that are independent of the
underlying storage. If you need those characteristics in your
remotely hosted VMs, then XFS is what you want regardless of how
much storage capability you buy for those VMs....
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:[~2012-02-01 23:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-30 9:18 File system remain unresponsive until the system is rebooted Supratik Goswami
2012-01-30 17:23 ` Peter Grandi
2012-01-31 1:31 ` Dave Chinner
2012-01-31 5:04 ` Supratik Goswami
2012-01-31 7:19 ` Emmanuel Florac
2012-01-31 9:04 ` Stan Hoeppner
2012-01-31 11:08 ` Emmanuel Florac
2012-02-01 12:31 ` Peter Grandi
2012-02-01 14:31 ` Emmanuel Florac
2012-02-01 22:20 ` Peter Grandi
2012-01-31 20:50 ` Dave Chinner
2012-02-01 0:20 ` Stan Hoeppner
2012-02-01 11:40 ` Peter Grandi
2012-02-01 23:55 ` Dave Chinner [this message]
2012-02-02 22:54 ` Peter Grandi
2012-02-03 1:32 ` Dave Chinner
2012-02-15 11:38 ` Michael Monnerie
2012-01-31 19:44 ` Dave Chinner
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=20120201235501.GX9090@dastard \
--to=david@fromorbit.com \
--cc=pg_xf2@xf2.to.sabi.co.UK \
--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