Hi We are using RAID-0 volumes as PV's in our LVM stack and XFS as the filesystem. The kernel logged the below call trace when the filesystem was being expanded using "xfs_growfs" command. We have us
LVM is in general a bad idea, and I have found that it occasionally interacts not so well with XFS and other filesystems under resource pressure. It also seems from one of the backtraces that you ar
Le Tue, 31 Jan 2012 10:34:10 +0530 vous écriviez: You can't know for sure what's happening behind the scenes. The most common problem of EC2 instances is IO starving, so this is hardly surprising. --
^^^^^^^^^^ 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 wish EC2 had been asked about du
Le Tue, 31 Jan 2012 03:04:18 -0600 Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx> écrivait: Oh come on, be nice for once :) People are constantly brainwashed about how "cloud computing" will solve financial
The growfs hang problem was fixed in 2.6.34. On earlier kernels, if you do a grow while the system is under allocation load it could deadlock. growing on a mostly idle filesystem was generally OK, bu
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 E
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
[ ... ] That's one use, but it is wider than that. Services like that are good for "emarassingly parallel" workloads, where the QoS of *a single* element does not matter, or even the *performance* (o
[ ... ] There are special cases, but «fsync heavy» is a bit of bad example. In general file system designs are not at all independent of the expected storage platform, and some designs are far better
Le Wed, 1 Feb 2012 12:31:53 +0000 pg_xf2@xxxxxxxxxxxxxxxxxx (Peter Grandi) écrivait: Thank you for all the good info. To add a last note, I use iSCSI to export lvm LVs to VMs from the host, and it wo
BTW, here I am not implying that EC2 allows one to «throw a lot of cheap ones at a problem», because the published "retail" price list is fairly expensive. But I guess that if one wants to buy «a lo
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 t
[ ... ] But this is better at being less bad. Because we are talking here about «fsync heavy» workloads on a VM, and these should not be run on a VM if performance matters. That's why I wrote about a
Whether or not you should put a workload that does fsyncs in a VM is a completely different argument altogether. It's not a meaningful argument to make when we are talking about how filesystems deal
Author: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 15 Feb 2012 12:38:52 +0100
Am Donnerstag, 2. Februar 2012, 22:54:09 schrieb Peter Grandi: Hi, I just took these lines to reply to your whole mail. I guess that the advantage of XFS will grow on a shared storage type like you t