[Bug 631296] New: xfs very slow compared to ext3
http://bugzilla.novell.com/show_bug.cgi?id=631296 http://bugzilla.novell.com/show_bug.cgi?id=631296#c0 Summary: xfs very slow compared to ext3 Classification: openSUSE Product: openSUSE 11.2 Version: Final Platform: x86-64 OS/Version: openSUSE 11.2 Status: NEW Severity: Major Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers@forge.provo.novell.com ReportedBy: martin@oneiros.de QAContact: qa@suse.de Found By: --- Blocker: --- Created an attachment (id=383015) --> (http://bugzilla.novell.com/attachment.cgi?id=383015) archive with test set User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.8) Gecko/20100723 SUSE/3.6.8-1.3 Firefox/3.6.8 I have a workload which on a fs with ext3 takes 2 seconds, while on a fs with xfs it takes 62 seconds. The test unjars some jars with ant twice; the second run of unjar is much slower on xfs then on ext3. How do I get xfs to be as fast as ext3? Reproducible: Always Steps to Reproduce: 1. Install ant and java, create an ext3 and an xfs fs (e.g. with yast), I tested with a size of 1GB 2. unpack the attached tar.gz on each fs 3. for every fs: cd test && sync && ant clean && ant && ant Actual Results: xfs: Total time: 1 minute 2 seconds ext3: Total time: 2 seconds Expected Results: The times should be the same on both partitions. I tried to tune the xfs fs and mount, but got no improvements. I testet with meta-data=/dev/mapper/system-xfs isize=256 agcount=8, agsize=32768 blks = sectsz=512 attr=2 data = bsize=4096 blocks=262144, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 and mounted with /dev/mapper/system-xfs on /space/tmp/mnt/xfs type xfs (rw,allocsize=1MB,attr2,barrier,noikeep,largeio,logbufs=8,logbsize=64k) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=631296 http://bugzilla.novell.com/show_bug.cgi?id=631296#c1 Harald Koenig <koenig@linux.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |koenig@linux.de --- Comment #1 from Harald Koenig <koenig@linux.de> 2010-08-16 12:46:04 UTC --- (In reply to comment #0)
The test unjars some jars with ant twice; the second run of unjar is much slower on xfs then on ext3.
How do I get xfs to be as fast as ext3?
by hacking/fixing jar ? a quick test with your example data shows: extracting jar files using "jar" is **VERY** slow on xfs when overwriting existing files (extracting into empty directry only is *slow*... ;) "unzip -o arch.jar" extracts/overwrites *much* faster on xfs than "jar xvf" strace shows: jar overwrites files like this open("file", , O_WRONLY|O_CREAT|O_TRUNC, 0666) while unzip first deletes the the existing file: unlink("file") open ("file", O_WRONLY|O_CREAT, 0644) which is a lot faster on xfs (no difference on ext4 which is again much faster than any of these xfs tests;) so maybe you want to fix (un)jar to 1st delete existing files.... -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=631296 http://bugzilla.novell.com/show_bug.cgi?id=631296#c2 --- Comment #2 from Martin Schröder <martin@oneiros.de> 2010-08-16 14:57:42 CEST --- (In reply to comment #1)
by hacking/fixing jar ?
Not an option. :-{
strace shows: jar overwrites files like this
open("file", , O_WRONLY|O_CREAT|O_TRUNC, 0666)
Yes. Why is that so much slower on xfs than on ext* or reiser? That can't be a feature. :-)
so maybe you want to fix (un)jar to 1st delete existing files....
Thank you for thinking outside of the box, but I want to know why xfs is so much slower here. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=631296 http://bugzilla.novell.com/show_bug.cgi?id=631296#c3 --- Comment #3 from Harald Koenig <koenig@linux.de> 2010-08-16 16:26:22 UTC --- (In reply to comment #2)
Thank you for thinking outside of the box, but I want to know why xfs is so much slower here.
because for xfs the file truncation is a (more) synchronous operation then in ext[234] ?! here is a small C program to trigger and bench the file truncation (needs one cmd line arg -- number of files to create/overwrite), kudos to Olaf Flebbe: --- 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< --- #include <stdio.h> #include <stdlib.h> main(int argc, char *argv[]) { FILE *fp; char *buf = malloc(64*1024); int i; for (i = 0; i < atoi(argv[1]); i++) { sprintf( buf, "testdat%04d", i); fp=fopen( buf,"w"); fwrite( buf, 1, 64*1024, fp); fclose(fp); } } -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=631296 https://bugzilla.novell.com/show_bug.cgi?id=631296#c4 Jeff Mahoney <jeffm@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |jeffm@novell.com Resolution| |WONTFIX --- Comment #4 from Jeff Mahoney <jeffm@novell.com> 2010-09-03 17:35:23 UTC --- openSUSE 11.2 is in security-maintenance mode. Please reopen if this issue still occurs with 11.3 or Factory. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com