| To: | stan@xxxxxxxxxxxxxxxxx |
|---|---|
| Subject: | Re: XFS: Abysmal write performance because of excessive seeking (allocation groups to blame?) |
| From: | Stefan Ring <stefanrin@xxxxxxxxx> |
| Date: | Tue, 10 Apr 2012 23:00:12 +0200 |
| Cc: | Martin Steigerwald <Martin@xxxxxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx |
| Dkim-signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zkJF50GiR1jLgRU7u3KErh8cUZOnYmQKfnezlxyLjo8=; b=PtiomPWGU8U5yZiup1vGcNhIUSuufQliHomXvCPv6YG/xdJ6meFKsVBWlD0YaXzV8u Ws5mU76wYMqTbNnHHNze7gk8EhQtfz3qJhShn/eskwawFXMcw1YHJM4A2u0HozIDD0HM tFpgS7rCkm76ARxwISnPlopDNon89LS/hdHZtlOxtT4TG2gnLiZn9bq6XR2e4gOWTqQP q/ogPjstQzPJQZO0d+XuVtR55QxYwodYdW4LlHxchQn7L8KdHgD8PcV4iEdYNB8askwo jI5c2pVmp+jQtiGjomsB0XRHpgo1ks728bV+YtlD80K53XUUU02nCMuJvlAzTbai+RmM VdpQ== |
| In-reply-to: | <4F849BAE.6070901@xxxxxxxxxxxxxxxxx> |
| References: | <CAAxjCEwBMbd0x7WQmFELM8JyFu6Kv_b+KDe3XFqJE6shfSAfyQ@xxxxxxxxxxxxxx> <20120405213740.GA22824@xxxxxxxxxxxxx> <CAAxjCExBcaB6J-u7ivZKWnKiF7oP10JRxzKzQNRuppHkTE2Tzw@xxxxxxxxxxxxxx> <201204072057.38286.Martin@xxxxxxxxxxxx> <CAAxjCEzRa7CpbA9iESEDjmWQMsJTjkWHJj69ADOXDa4CiRpx3w@xxxxxxxxxxxxxx> <4F849BAE.6070901@xxxxxxxxxxxxxxxxx> |
> Is the LVM volume aligned to the RAID stripe? Is their a partition atop > the RAID LUN and under LVM? Is the partition aligned? Why LVM anyway? Yes, it is aligned. I followed the advice from <http://www.mysqlperformanceblog.com/2011/06/09/aligning-io-on-a-hard-disk-raid-the-theory/>. Why LVM? Because we use it on lots of servers, and there is some value to having a somewhat similar setup in development as in production. I’ve done similar tests time and again with LVM and without, and I’ve never ever measured a significant difference. I haven’t re-tested it this time, true, but I would be surprised if it would magically behave completely differently this time. > The devil is always in the details. Were you using partitions and LVM > with the RAID1 concat tesing? With the free space testing? I used LVM linear for the concatenation – one volume group made from 3 physical volumes. The pvols were on primary partitions. The one-volume RAID 6 is set up similarly; from only one pvol of course. > I assumed you were directly formatting the LUN with XFS. With LVM and > possibly partitions involved here, that could explain some of the > mediocre performance across the board, with both EXT4 and XFS. If one > wants maximum performance from their filesystem, one should typically > stay away from partitions and LVM, and any other layers that can slow IO > down. I don’t want maximum performance, I want acceptable performance ;). This means, I am satisfied with 80% or more of what’s possible, but I’m not satisfied with 15%. |
| Previous by Date: | Re: XFS: Abysmal write performance because of excessive seeking (allocation groups to blame?), Stan Hoeppner |
|---|---|
| Next by Date: | [XFS updates] XFS development tree branch, master, updated. v3.2-rc1-23753-g0034102, xfs |
| Previous by Thread: | Re: XFS: Abysmal write performance because of excessive seeking (allocation groups to blame?), Stan Hoeppner |
| Next by Thread: | Re: XFS: Abysmal write performance because of excessive seeking (allocation groups to blame?), Roger Willcocks |
| Indexes: | [Date] [Thread] [Top] [All Lists] |