[Top] [All Lists]

Re: XFS: Abysmal write performance because of excessive seeking (allocat

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: Fri, 6 Apr 2012 17:37:32 +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=+TucTeR3Dc0ckSuU9zdpyJrP1cQVjwCxKqzr3NynThU=; b=1FQX55BX3wDhtumzU0Ptnd7Zy8YgqVvOKbEALRPagZ8AFSGwOAhoWjIDW0HY1nTa8m apBfZ1SOdBO6debiLoRnH0H4xmmlccITldgpSn3/ii6Vhqnzn3mpnLVpwfNnO2d+WL5I 2/vkK7snPedZXJWK5GFEfd8/P1jqhKmSYgxDXxQNyk+l86uW6qF7H3EmsZfo+Of1cHq6 wOxqUUMz1OUjTqrBmTWlGIyjx6kf6XPtHhQRlONPeEtP3E9iLdpq/cnR07sRfxqOygQb 2s37DSrvVWA0SGqQvn13gqcUMh40e9gW7mpqB05X/LIbNzjosoY6qBssfT86vezZJQdf RV5A==
In-reply-to: <20350.65390.662663.682964@xxxxxxxxxxxxxxxxxx>
References: <CAAxjCEwBMbd0x7WQmFELM8JyFu6Kv_b+KDe3XFqJE6shfSAfyQ@xxxxxxxxxxxxxx> <20349.63706.913104.777446@xxxxxxxxxxxxxxxxxx> <20350.65390.662663.682964@xxxxxxxxxxxxxxxxxx>
> As to 'ext4' and doing (euphemism) insipid tests involving
> peculiar setups, there is an interesting story in this post:
>  http://oss.sgi.com/archives/xfs/2012-03/msg00465.html

I really don't see the connection to this thread. You're advocating
mostly that tar use fsync on every file, which to me seems absurd. If
the system goes down halfway through tar extraction, I would delete
the tree and untar again. What do I care if some files are corrupt,
when the entire tree is incomplete anyway?

Despite the somewhat inflammatory thread subject, I don't want to bash
anyone. It's just that untarring large source trees is a very typical
workload for me. And I just don't want to accept that XFS cannot do
better than being several orders of magnitude slower than ext4
(speaking of binary orders of magnitude). As I see it, both file
systems give the same guarantees:

1) That upon completion of sync, all data is readily available on
permanent storage.
2) That the file system metadata doesn't suffer corruption, should the
system lose power during the operation.

<Prev in Thread] Current Thread [Next in Thread>