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
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....