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@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
