MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16804.15883.954229.326178@samba.org>
Date: Wed, 24 Nov 2004 18:53:47 +1100
To: Andrew Morton <akpm@osdl.org>
Cc: adilger@clusterfs.com, linux-kernel@vger.kernel.org
Subject: Re: performance of filesystem xattrs with Samba4
In-Reply-To: <20041119162651.2d62a6a8.akpm@osdl.org>
References: <16797.41728.984065.479474@samba.org>
	<419E1297.4080400@namesys.com>
	<16798.31565.306237.930372@samba.org>
	<20041119162651.2d62a6a8.akpm@osdl.org>
Reply-To: tridge@samba.org
From: tridge@samba.org
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 956
Lines: 24

Andrew,

You can call off your bsearch - I found the culprit.

For the 2.6.10-rc2 tests I was running with the patch from Andreas
that added large ext3 inode support (in order to also test the
ext3-256 case). For the -mm2 test I wasn't.

This patch was supposed to have no effect if large inodes were not
setup at mkfs time. Unfortunately it does have an affect as it also
removes the in-place xattr modification logic from
ext3_xattr_set_handle(), so every xattr set becomes the same as a
delete+create pair. In plain -rc2 and in -mm2 an xattr set of the same
size will be done in-place. As every xattr set is of the same size in
dbench3 this made a huge difference.

Sorry for the false alarm.

Cheers, Tridge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/