Bug 631296

(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....

(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.

(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);
  }
}

openSUSE 11.2 is in security-maintenance mode. Please reopen if this issue still occurs with 11.3 or Factory.