On 10/25/2012 12:09 PM, Alex Lyakas wrote:
Wade, thanks.Yes, with the preallocated extent I saw the behavior you describe, and it makes perfect sense to alloc a new EXTENT_DATA in this case. In my case, I did another simple test: Before: item 4 key (257 INODE_ITEM 0) itemoff 3593 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 5 key (257 INODE_REF 256) itemoff 3578 itemsize 15 inode ref index 2 namelen 5 name: vol-1 item 6 key (257 EXTENT_DATA 0) itemoff 3525 itemsize 53 extent data disk byte 5368709120 nr 131072 extent data offset 0 nr 131072 ram 131072 extent compression 0 item 7 key (257 EXTENT_DATA 131072) itemoff 3472 itemsize 53 extent data disk byte 5905842176 nr 33423360 extent data offset 0 nr 33423360 ram 33423360 extent compression 0 ... I am going to do a single write of a 4Kib block into (257 EXTENT_DATA 131072) extent: dd if=/dev/urandom of=/mnt/src/subvol-1/vol-1 bs=4096 seek=32 count=1 conv=notrunc After: 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 1 item 5 key (257 INODE_REF 256) itemoff 3578 itemsize 15 inode ref index 2 namelen 5 name: vol-1 item 6 key (257 EXTENT_DATA 0) itemoff 3525 itemsize 53 extent data disk byte 5368709120 nr 131072 extent data offset 0 nr 131072 ram 131072 extent compression 0 item 7 key (257 EXTENT_DATA 131072) itemoff 3472 itemsize 53 extent data disk byte 5368840192 nr 4096 extent data offset 0 nr 4096 ram 4096 extent compression 0 item 8 key (257 EXTENT_DATA 135168) itemoff 3419 itemsize 53 extent data disk byte 5905842176 nr 33423360 extent data offset 4096 nr 33419264 ram 33423360 extent compression 0 We clearly see that a new extent has been allocated for some reason (bytenr=5368840192), and previous extent (bytenr=5905842176) is still there, but used at offset of 4096. This is exactly cow, I believe.
Hmm, I'm pretty sure that using 'dd' in this fashion skips the first 32 4096-sized blocks and thus writes -past- the length of this extent (eg: writes from 131073 to 135168). This causes a new extent to be allocated after the previous extent. But even if using 'dd' with a 'skip' value of '31' created a new EXTENT_DATA, it would not necessarily be data CoW, since data CoW refers only to the location of the -data- (i.e., not metadata and thus not EXTENT_DATA) on disk. The key thing is to look at where the EXTENT_DATAs are pointing to, not how many EXTENT_DATAs there are.
However, your hint about not being able to read into memory may be useful; it would be good if we can find the place in the code that does that decision to cow.
Try looking at the callers of btrfs_cow_block(), but you'll be own your own from there :)
I guess I am looking for a way to never ever allocate new EXTENT_DATAs on a fully-mapped file. Is there one?
Hmm, I don't think that this exists right now. You could try a '-o autodefrag' to minimize the number of EXTENT_DATAs, though. Regards, Wade
Thanks! Alex.
-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
