Hi everybody, I need some help understanding the nodatacow behavior. I have set up a large file (5GiB), which has very few EXTENT_DATAs (all are real, not bytenr=0). The file has NODATASUM and NODATACOW flags set (flags=0x3): item 4 key (257 INODE_ITEM 0) itemoff 3591 itemsize 160 inode generation 5 transid 5 size 5368709120 nbytes 5368709120 owner[0:0] mode 100644 inode blockgroup 0 nlink 1 flags 0x3 seq 0 item 7 key (257 EXTENT_DATA 131072) itemoff 3469 itemsize 53 item 8 key (257 EXTENT_DATA 33554432) itemoff 3416 itemsize 53 item 9 key (257 EXTENT_DATA 67108864) itemoff 3363 itemsize 53 item 10 key (257 EXTENT_DATA 67112960) itemoff 3310 itemsize 53 item 11 key (257 EXTENT_DATA 67117056) itemoff 3257 itemsize 53 item 12 key (257 EXTENT_DATA 67121152) itemoff 3204 itemsize 53 item 13 key (257 EXTENT_DATA 67125248) itemoff 3151 itemsize 53 item 14 key (257 EXTENT_DATA 67129344) itemoff 3098 itemsize 53 item 15 key (257 EXTENT_DATA 67133440) itemoff 3045 itemsize 53 item 16 key (257 EXTENT_DATA 67137536) itemoff 2992 itemsize 53 item 17 key (257 EXTENT_DATA 67141632) itemoff 2939 itemsize 53 item 18 key (257 EXTENT_DATA 67145728) itemoff 2886 itemsize 53 item 19 key (257 EXTENT_DATA 67149824) itemoff 2833 itemsize 53 item 20 key (257 EXTENT_DATA 67153920) itemoff 2780 itemsize 53 item 21 key (257 EXTENT_DATA 67158016) itemoff 2727 itemsize 53 item 22 key (257 EXTENT_DATA 67162112) itemoff 2674 itemsize 53 item 23 key (257 EXTENT_DATA 67166208) itemoff 2621 itemsize 53 item 24 key (257 EXTENT_DATA 67170304) itemoff 2568 itemsize 53 item 25 key (257 EXTENT_DATA 67174400) itemoff 2515 itemsize 53 extent data disk byte 67174400 nr 5301534720 extent data offset 0 nr 5301534720 ram 5301534720 extent compression 0 As you see by last extent, the file size is exactly 5Gib. Then I also mount btrfs with nodatacow option. root@vc:/btrfs-progs# ./btrfs fi df /mnt/src/ Data: total=5.47GB, used=5.00GB System: total=32.00MB, used=4.00KB Metadata: total=512.00MB, used=28.00KB (I have set up block groups myself by playing with mfks code and convertion code to learn about the extent tree. The filesystem passes btrfsck fine, with no errors. All superblock copies are consistent.) Then I run parallel random IOs on the file, and almost immediately hit ENOSPC. When looking at the file, I see that now it has a huge amount of EXTENT_DATAs: item 4 key (257 INODE_ITEM 0) itemoff 3593 itemsize 160 inode generation 5 transid 21 size 5368709120 nbytes 5368709120 owner[0:0] mode 100644 inode blockgroup 0 nlink 1 flags 0x3 seq 130098 item 6 key (257 EXTENT_DATA 0) itemoff 3525 itemsize 53 item 7 key (257 EXTENT_DATA 131072) itemoff 3472 itemsize 53 item 8 key (257 EXTENT_DATA 262144) itemoff 3419 itemsize 53 item 9 key (257 EXTENT_DATA 524288) itemoff 3366 itemsize 53 item 10 key (257 EXTENT_DATA 655360) itemoff 3313 itemsize 53 item 11 key (257 EXTENT_DATA 1310720) itemoff 3260 itemsize 53 item 12 key (257 EXTENT_DATA 1441792) itemoff 3207 itemsize 53 item 13 key (257 EXTENT_DATA 2097152) itemoff 3154 itemsize 53 item 14 key (257 EXTENT_DATA 2228224) itemoff 3101 itemsize 53 item 15 key (257 EXTENT_DATA 2752512) itemoff 3048 itemsize 53 item 16 key (257 EXTENT_DATA 2883584) itemoff 2995 itemsize 53 item 17 key (257 EXTENT_DATA 11927552) itemoff 2942 itemsize 53 item 18 key (257 EXTENT_DATA 12058624) itemoff 2889 itemsize 53 item 19 key (257 EXTENT_DATA 13238272) itemoff 2836 itemsize 53 item 20 key (257 EXTENT_DATA 13369344) itemoff 2783 itemsize 53 item 21 key (257 EXTENT_DATA 16646144) itemoff 2730 itemsize 53 item 22 key (257 EXTENT_DATA 16777216) itemoff 2677 itemsize 53 item 23 key (257 EXTENT_DATA 17432576) itemoff 2624 itemsize 53 ... and: root@vc:/btrfs-progs# ./btrfs fi df /mnt/src/ Data: total=5.47GB, used=5.46GB System: total=32.00MB, used=4.00KB Metadata: total=512.00MB, used=992.00KB Kernel is for-linus branch from Chris's tree, up to f46dbe3dee853f8a860f889cb2b7ff4c624f2a7a (this is the last commit there now). I was under impression that if a file is marked as NODATACOW, then new writes will never allocate EXTENT_DATAs if appropriate EXTENT_DATAs already exist. However, it is clearly not the case, or maybe I am doing something wrong. Can anybody please help me to debug further and understand why this is happening. Thanks, Alex. -- 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
