Thanks, Liu, that clarifies.

Alex.

On Tue, May 22, 2012 at 4:42 AM, Liu Bo <liubo2...@cn.fujitsu.com> wrote:
> On 05/21/2012 06:05 PM, Alex Lyakas wrote:
>
>> 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.
>>
>
>
> As I mentioned, disk_bytenr == 0 means dummy extents, which we have not yet 
> allocate
> a range of space for it.
>
> After your first 'size=5' inline extent, we'll start allocating extents from 
> _4096_, cause
> it is _4k aligned_.
>
>>> 1) dd if=/dev/zero of=/mnt/btrfs/foobar bs=1k seek=12 count=4 
>>> conv=notrunc;sync
> : we need a dummy extent for [4k, 12k], which starts from 4096, and nr is 8192
>
>>> 2) dd if=/dev/zero of=/mnt/btrfs/foobar bs=1k seek=8 count=4 
>>> conv=notrunc;sync
> : we break [4k, 12k] into a dummy one [4k, 8k] and a real one [8k, 12k].
>
> More details, plz refer to btrfs_drop_extents();
>
> thanks,
> liubo
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to