File system remain unresponsive until the system is rebooted.
stan at hardwarefreak.com
Tue Jan 31 18:20:49 CST 2012
On 1/31/2012 2:50 PM, Dave Chinner wrote:
> On Tue, Jan 31, 2012 at 03:04:18AM -0600, Stan Hoeppner wrote:
>> On 1/30/2012 11:04 PM, Supratik Goswami wrote:
>>> We are using Amazon EC2 instances.
>> I'd have never thought I would see those words on this list, except
>> maybe as a joke, or as an example of 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...
>> I wish EC2 had been asked about during the QA session after Dave's
>> presentation. I'm guessing some laughter would have been involved. ;)
> You'd be wrong about that. There are as many good uses of cloud
> services as there are bad ones, yet the same decisions about storage
> need to be made even when services are remotely hosted....
Maybe I should have elaborated a bit. My thinking is that workloads
that would require XFS, or benefit most from it, are probably going to
need more guarantees WRT bandwidth and IOPS being available
consistently, vs sharing said resources with other systems in the cloud
infrastructure. Additionally, you have driven the point home many times
WRT tuning XFS to the underlying hardware, specifically stripe
alignment. I'd bet alignment would be a bit tricky to achieve in a
cloud environment such as EC2.
In summary, I wasn't saying XFS is bad on EC2. I was simply saying EC2
is probably bad for the typical workloads where XFS best flexes its muscles.
More information about the xfs