Michael Schmitz wrote:
BTW, I have straced "tar -C /usr/bin -c ." and found out that 'getdents64()' returns those corrupted filenames:You mean, you pipe the output of this to /dev/null and wait for error messages?
yes
How many repetitions?
it doesn't matter. It's 99+% reproducible so it's OK to run it under strace etc - it's always doing the same thing, i.e. failing with corrupted "slabtop"->"slabt".
Doesn't throw an error right away for me... not even with your kernel image used.
now that smells. A timing problem caused by different host speed? :-O
Can't reproduce this; I've upgraded all disk images to testing in the meantime, though.
I can reproduce it with both sarge and etch disk images I uploaded to web. But with sarge I had different filenames "corrupted". Maybe you could try the etch.img I uploaded - if you don't mind downloading 143 MB file. Perhaps it depends on the number of files in a directory or something like that.
PetrP.S. I'll retest the etch.img and "tar -C /usr/bin -c . >/dev/null" on another, slightly faster (K7 2500+) host. I'd let you know if it behaved differently.