| To: | Linux fs XFS <xfs@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: XFS: Abysmal write performance because of excessive seeking (allocation groups to blame?) |
| From: | Stefan Ring <stefanrin@xxxxxxxxx> |
| Date: | Tue, 10 Apr 2012 15:59:37 +0200 |
| 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 :content-type:content-transfer-encoding; bh=YgMq+mUcsreZllxaT9LZL7PO6uCP/6FjMwY8a4KMl/c=; b=Ff+oytxSH0/V7kMakPU+O2ZFd6ESCzd6ubdZnjTvBfm3UDYTxW57qBwkp72vrzm5Or nGraohhpCkKT6dYCtQdlT+Je+Tok4W43unXQBe+aOy5TARsHTiTu7GaNDkyUMo4nE/Wg RBlsuOKXxrktMYXJ5ZjjNioESFQDcu4oM+UYhB10sH0tGks1rn08+XLh2W2X/6ef01e6 PrXeMrnrNkOZyq6NyrvSn2R3Es9CzjQ4DWYl8icwNU0XKOHSiHpnywDLamREPiJcIG+N GtBkNndSeHCHZ+KLdJ7u+BGYvakM/bOP/AwGhPeQ+xESxMcASo+SAbxQL0oBdstsP8Hy hDEw== |
| In-reply-to: | <4F83E293.8000509@xxxxxxxxxxxxxxxxx> |
| References: | <CAAxjCEwBMbd0x7WQmFELM8JyFu6Kv_b+KDe3XFqJE6shfSAfyQ@xxxxxxxxxxxxxx> <20350.9643.379841.771496@xxxxxxxxxxxxxxxxxx> <20350.13616.901974.523140@xxxxxxxxxxxxxxxxxx> <CAAxjCEzkemiYin4KYZX62Ei6QLUFbgZESdwS8krBy0dSqOn6aA@xxxxxxxxxxxxxx> <20352.28730.273834.568559@xxxxxxxxxxxxxxxxxx> <4F8074EC.2030108@xxxxxxxxx> <4F82063F.4070609@xxxxxxxxxxxxxxxxx> <4F826FFA.4050207@xxxxxxxxxxxxxxxxx> <CAAxjCExcd6T9gUM5AHzZM535e1kyb9WJd_ib2MFkeC_DbU7TXA@xxxxxxxxxxxxxx> <4F83E293.8000509@xxxxxxxxxxxxxxxxx> |
> With 4 AGs this must represent the RAID6 or RAID10 case. Yes, the original RAID 6 case. >> Yes, in theory, a good cache controller should be able to sort this >> out. But at least this particular controller is not able to do so and >> could use a little help. > > Is the cache in write-through or write-back mode? The latter should > allow for aggressive reordering. The former none, or very little. And > is all of it dedicated to writes, or is it split? If split, dedicate it > all to writes. Linux is going to cache block reads anyway, so it makes > little sense to cache them in the controller as well. The cache is a write-back cache. Yes, it’s split 75% write / 25% read. Changing to 100% write does not make a difference. I can imagine that the small read cache might be beneficial for partial stripe writes, when the stripe contents from the untouched drives are in cache. >> Also, a single consumer-grade drive is >> certainly not helped by this write ordering. > > Are you referring to the Mushkin SSD I mentioned? No, I meant rotational storage. But even SSDs should gain at least a little from a linear write pattern. |
| Previous by Date: | Re: [PATCH] 273: don't delete everything if $SCRATCH_MNT isn't set, Bryan Schumaker |
|---|---|
| Next by Date: | Re: XFS: Abysmal write performance because of excessive seeking (allocation groups to blame?), Stefan Ring |
| 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?), Stefan Ring |
| Indexes: | [Date] [Thread] [Top] [All Lists] |