Hi Liu, thanks for the clarifications. I did not understand the dd example of yours, though. > So for the following situation: >> item 23 key (266 EXTENT_DATA 4096) itemoff 2269 itemsize 53 >> extent data disk byte 0 nr 0 >> extent data offset 0 nr 4096 ram 8192 >> extent compression 0 > > As your case, after the first 'size 5' inline extent is written, > "nr 4096 < ram 8192" could come from: > 1) dd if=/dev/zero of=/mnt/btrfs/foobar bs=1k seek=12 count=4 conv=notrunc;sync > 2) dd if=/dev/zero of=/mnt/btrfs/foobar bs=1k seek=8 count=4 conv=notrunc;sync > > 1) makes >> item 23 key (266 EXTENT_DATA 4096) itemoff 2269 itemsize 53 >> extent data disk byte 0 nr 0 >> extent data offset 0 nr 8192 ram 8192 >> extent compression 0 > > 2) makes >> item 23 key (266 EXTENT_DATA 4096) itemoff 2269 itemsize 53 >> extent data disk byte 0 nr 0 >> extent data offset 0 nr 4096 ram 8192 >> extent compression 0 You talk about the "ram_bytes" field. But do I need to look at it, if I don't use compression or another encoding? Shouldn't I always look at btrfs_file_extent_item::offset/num_bytes for the real data, and at btrfs_file_extent_item::disk_bytenr/disk_num_bytes for finding CHUNK_ITEM? Any reason I should be aware of "ram_bytes" field? The first dd created a 4k extent at offset 12k. How did we end up with "nr 8192 ram 8192" and offset 4k? The second dd added a 4k extent at 8k offset. But still EXTENT_DATA has 4k offset. So now we should have have twp 4k extents or one 8k extent. What am I missing? 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
