| 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 17:56:57 +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=ZLhC4hFmThcqIHe5NDTtTnVlaBgbyOXLsK8CzTjeguo=; b=OkTO7RG/trsgW1IdEWyL+4reVht4NvCOzzX3q1mkJYXb6mZvkJUE82onTUMzKOeVzV H74el1RX4O3ZQU2tGWpnEizBS2OngLTW5dNONFHXds24BH1uDhEbMrF9o9nYKrLnmmgr M3FEX59jS276v1VGwoZMUXzIQXO6do4qZ2iR1TFQQlBYVNGmEAq5RNIyaUL8FfAkifrS RyQ27ATqTxsaTJQj31PMP0+RkaYwL4kFUgfccgGSbdCtf+7nIaLQUbBzu2uClPhnTPHm CCGT2gEqiICyT2DdiWAHCcU5dD1N7I9SlP9Hvb1qm58xswPZANWkib3QpkTrnB36iZBE SIQw== |
| In-reply-to: | <4F844474.3010005@xxxxxxxxx> |
| References: | <CAAxjCEwBMbd0x7WQmFELM8JyFu6Kv_b+KDe3XFqJE6shfSAfyQ@xxxxxxxxxxxxxx> <20120405213740.GA22824@xxxxxxxxxxxxx> <CAAxjCExBcaB6J-u7ivZKWnKiF7oP10JRxzKzQNRuppHkTE2Tzw@xxxxxxxxxxxxxx> <201204072057.38286.Martin@xxxxxxxxxxxx> <CAAxjCEzRa7CpbA9iESEDjmWQMsJTjkWHJj69ADOXDa4CiRpx3w@xxxxxxxxxxxxxx> <4F844474.3010005@xxxxxxxxx> |
> try 128k to 512k for stripe size. And try to increase your agcount by > (nearly) an order of magnitude. Would that be of any real value to anyone here, except for satisfying curiosity (which I feel as well ;))? Because frankly, it’s a lot of work, and I’m quite through with this tedious kind of activity… My conclusion is that everything should work well if the levels below the file system behaved the way they should and brought the writes into a sane order. Apparently, both the RAID controller as well as the Linux block scheduler fail to do so. Despite the annoying nature of this state of affairs, I do believe that file systems should be able to count on the lower levels of the stack for such low-level work and not work around them, but apparently, they are often failed. Probably that’s one of the reasons why almost every file system acquires some sort of block scheduling over time. Maybe some day, the Linux IO scheduler will do a better job. Unfortunately, by then, this entire issue will be irrelevant because nobody will be using rotational storage anymore, at least not for everyday work. |
| Previous by Date: | Re: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1518 of file fs/xfs/xfs_alloc.c., Robert Bennett |
|---|---|
| Next by Date: | Re: [PATCH] set freed perag structures to NULL to avoid mount failure oops, Eric Sandeen |
| Previous by Thread: | Re: XFS: Abysmal write performance because of excessive seeking (allocation groups to blame?), Joe Landman |
| Next by Thread: | Re: XFS: Abysmal write performance because of excessive seeking (allocation groups to blame?), Martin Steigerwald |
| Indexes: | [Date] [Thread] [Top] [All Lists] |