http://lwn.net/Articles/112566/ This is a special feed containing comments posted to the individual LWN article titled "Which filesystem for Samba4?". hourly 2 http://lwn.net/Articles/112952/rss 2004-11-27T03:24:08+00:00 stevef The working set seems to have been too small to cause much disk activity which may explain the counterintutive result (ext3 being faster than jfs and xfs). Most of the data I have seen on larger server benchmarks (whose working set exceeds physical memory) showed ext3 somewhat worse. The updates to ext3 seem promising though. <br> <p> In any case a good xattr performance test ala iozone or equivalent would be helpful as well.<br> http://lwn.net/Articles/112695/rss 2004-11-24T14:25:50+00:00 rl The mystery has been solved. <p> <i> From: tridge@samba.org <br> Date: Wed, 24 Nov 2004 18:53:47 +1100 <p> You can call off your bsearch - I found the culprit. <p> 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. <p> 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. </i>