On 4/14/11 9:59 AM, Pádraig Brady wrote: > On 14/04/11 15:02, Markus Trippelsdorf wrote: >>>> Hi Pádraig, >>>> >>>> here you go: >>>> + filefrag -v unwritten.withdata >>>> Filesystem type is: ef53 >>>> File size of unwritten.withdata is 5120 (2 blocks, blocksize 4096) >>>> ext logical physical expected length flags >>>> 0 0 274432 2560 unwritten,eof >>>> unwritten.withdata: 1 extent found >>>> >>>> Please notice that this also happens with ext4 on the same kernel. >>>> Btrfs is fine. >>> >> `filefrag -vs` fixes the issue on both xfs and ext4. > > So in summary, currently on (2.6.39-rc3), the following > will (usually?) report a single unwritten extent, > on both ext4 and xfs > > fallocate -l 10MiB -n k > dd count=10 if=/dev/urandom conv=notrunc iflag=fullblock of=k > filefrag -v k # grep for an extent without unwritten || fail right, that's what I see too in testing. But would the coreutils install have done a preallocation of the destination file? Otherwise this looks like a different bug... > This particular issue has been discussed so far at: > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8411 > Note there it was stated there that ext4 had this > fixed as of 2.6.39-rc1, so maybe there is something lurking? ext4 got a fix, but not xfs, I guess. My poor brain can't remember, I think I started looking into it, but it's clearly still broken. Still, I don't know for sure what happened to Markus - did something preallocate, in his case? -Eric > cheers, > Pádraig. > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
