| To: | Emmanuel Florac <eflorac@xxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: XFS: Abysmal write performance because of excessive seeking (allocation groups to blame?) |
| From: | Stefan Ring <stefanrin@xxxxxxxxx> |
| Date: | Fri, 13 Apr 2012 21:36:19 +0200 |
| Cc: | stan@xxxxxxxxxxxxxxxxx, 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=50eCl9Y2zsH21d+i5aceFOHo+9vEJXrZRgvxy9XXE5w=; b=s4kgQDPgcGi3I+2nZpXbSPxGksk7Pf+giiTWac8CWpjwIKMV5gCmbw7t/csUtM9TVb 97umzu0lbo4Ft2/quxPlySiKbwDo39sQiH3MpYSKel9DjlDdbYIDzTewwqIYwIzy24Dq XLvds9UV9Yx2MuOg/DSVB9D+n4CWLVe4CN6od9fwPWX0NCgfVIAxzLHdP6N319w+XRu7 FYVAyNz9Rd89Cum11YGK8dvgw2UfdldcGwtOwHbpA/tO8blgrBHqhpcCz4bNyTYiF6N3 mBx0biuwxFnnvGzH/pstfjiGelc6i/H2v6Jh4884f8AvJrBvMTVieMDJOKnmGjLl+q5E 5u6w== |
| In-reply-to: | <20120409144558.6072c1eb@xxxxxxxxxxxxxx> |
| References: | <CAAxjCEwBMbd0x7WQmFELM8JyFu6Kv_b+KDe3XFqJE6shfSAfyQ@xxxxxxxxxxxxxx> <20350.9643.379841.771496@xxxxxxxxxxxxxxxxxx> <20350.13616.901974.523140@xxxxxxxxxxxxxxxxxx> <CAAxjCEzkemiYin4KYZX62Ei6QLUFbgZESdwS8krBy0dSqOn6aA@xxxxxxxxxxxxxx> <4F7F7C25.8040605@xxxxxxxxxxxxxxxxx> <20120407104912.44881be3@xxxxxxxxxxxxxx> <4F81F5FD.1090809@xxxxxxxxxxxxxxxxx> <20120408234555.695e291f@xxxxxxxxxxxxxx> <4F827341.2000607@xxxxxxxxxxxxxxxxx> <20120409144558.6072c1eb@xxxxxxxxxxxxxx> |
> Let's rerun it with files cached (the machine has 16 GB RAM, so > every single file must be cached): > > # time tar xf test.tar > > real 0m50.842s > user 0m0.809s > sys 0m13.767s That’s about the same time I’m getting on a fresh (non-fragmented) file system with the RAID 6 volume. Interestingly, the P400’s successor, the P410 does recognize a setting that the P400 lacks, which is called elevatorsort. It sounds like this could make all the difference. Unfortunately, the P400 doesn’t have it. I don’t have a P410 with more than 2 drives to test this, but some effect should definitely be measurable. Since this finding has piqued my interest again, I’m willing to invest a little more time, but I’m completely occupied for the next few days, so it will have to wait a while. |
| Previous by Date: | Re: [PATCH 06/18] xfs: fix buffer lookup race on allocation failure, Mark Tinguely |
|---|---|
| Next by Date: | Re: [PATCH 15/18] xfs: kill XBF_LOCK, Mark Tinguely |
| Previous by Thread: | Re: XFS: Abysmal write performance because of excessive seeking (allocation groups to blame?), Emmanuel Florac |
| Next by Thread: | Re: XFS: Abysmal write performance because of excessive seeking (allocation groups to blame?), Stan Hoeppner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |