2011/2/19 Pádraig Brady: > On 19/02/11 18:28, Mike Frysinger wrote: >> based on other threads (which i havent been following too closely), did we >> settle on this being a btrfs bug ? > > Nope, cp 8.10 is not absolved yet. > It may be btrfs not honoring FIEMAP_FLAG_SYNC, > and/or it may be cp needing to handle FIEMAP_EXTENT_ENCODED > specially. > > It would help if you ran `sync` before the copy, > to exclude that as a possible issue. makes no difference after applying this patch: --- coreutils-8.10/tests/cp/fiemap-2 +++ coreutils-8.10/tests/cp/fiemap-2 @@ -43,12 +43,19 @@ printf x > k || framework_failure_ dd bs=1k seek=1 of=k count=255 < /dev/zero || framework_failure_ +filefrag -v k +sync +filefrag -v k + # cp should detect the all-zero blocks and convert some of them to holes. # How many it detects/converts currently depends on io_blksize. # Currently, on my F14/ext4 desktop, this K starts off with size 256KiB, # (note that the K in the preceding test starts off with size 4KiB). # cp from coreutils-8.9 with --sparse=always reduces the size to 32KiB. cp --sparse=always k k2 || fail=1 + +sync + test $(stat -c %b k2) -lt $(stat -c %b k) || fail=1 Exit $fail > Also `filefrag -v` output for the file on > the compressed BTRFS file system would be helpful. the output from the aforementioned patch: ... + dd bs=1k seek=1 of=k count=255 255+0 records in 255+0 records out 261120 bytes (261 kB) copied, 0.00313737 s, 83.2 MB/s + filefrag -v k Filesystem type is: 9123683e File size of k is 262144 (64 blocks, blocksize 4096) ext logical physical expected length flags k: 1 extent found + sync + filefrag -v k Filesystem type is: 9123683e File size of k is 262144 (64 blocks, blocksize 4096) ext logical physical expected length flags 0 0 47917 32 1 32 47918 47948 32 eof k: 2 extents found ... -mike -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
