Hi Matt,
I want to delay the assignment of blocks to the dnode.
So whenever I need a block I will call metaslab_alloc which is internal
part of zio pipeline.
This metaslab_alloc will return me the blkptr with blk_birth as say 123.
I will issue the Zio to write data to the disk with this blkptr.
Now After some time I want to assign this block to some particular dnode.
So I will just update the level 1 indirect block of the dnode with the
blkptr we created earlier.
So the assignment will have different txg say 456,
So when i update the blkptr with indirect block I need to update the
logical birth time of block i.e. blk_birth with 456 So that DSL and DMU
will consider the block as if it was created in txg=456. But the
blk_phys_birth will remain to 123 which is the actual birth time of the
block.
Now in this case I dont have dedupe enabled. I just wanted to confirm that
if I have dedupe disabled and a block with different blk_birth and
blk_phys_birth then will this work?. Or it will cause any problem.?
Thanks,
Gaurav.
On Tue, Oct 15, 2013 at 11:36 AM, Matthew Ahrens <mahr...@delphix.com>wrote:
>
>
>
> On Mon, Oct 14, 2013 at 10:53 PM, Gaurav Mahajan <gaurav...@gmail.com>wrote:
>
>> Hi Matt,
>>
>> Thanks for the reply.
>> So can it happen like block gets physically allocate in one txg (say
>> txg=123) using metaslab_alloc()
>> So the blkptr will have only blk_birth=123 and bkp_phys_birth=0.
>>
>
>
>> Later on this block gets assigned to a Dnode (lets say ion txg 456)
>>
>
> What do you mean by that? If it was written as part of that dnode then it
> would be "assigned" in the same txg, 123. Or do you mean the same data is
> later written to a different file and you have dedup enabled?
>
>
>> then we can modify the blkptr as blk_birth=456 and blk_phys_birth=123.
>>
>
> blkptrs are not modified once they are on disk.
>
>
>>
>> Would this work? this would work only in case we have dedupe enabled.
>>
>
> If you had dedup enabled, and you write data that is identical to a block
> that already exists, it will have blk_phys_birth = whenever it was first
> written, some time in the past; and blk_birth = now, when the new reference
> is created to the existing physical block.
>
> --matt
>
>
>>
>> Thanks,
>> Gaurav
>>
>>
>> On Tue, Oct 15, 2013 at 10:59 AM, Matthew Ahrens <mahr...@delphix.com>wrote:
>>
>>> On Wed, Oct 9, 2013 at 3:35 AM, Gaurav Mahajan <gaurav...@gmail.com>wrote:
>>>
>>>> Hi,
>>>>
>>>> I am new to ZFS and trying to understand the code and workflow.
>>>>
>>>> In blkptr structure there are blk_phys_birth and blk_birth are nothing
>>>> but the txgs.
>>>>
>>>> What is the difference between them?
>>>> How DDT uses these two fields?
>>>>
>>>> typedef struct blkptr {
>>>> ....
>>>> uint64_t blk_phys_birth; /* txg when block was allocated */
>>>> uint64_t blk_birth; /* transaction group at birth */
>>>> .....
>>>> } blkptr_t;
>>>>
>>>>
>>> blk_birth_phys is when the block was allocated.
>>> blk_birth is when this particular reference was created.
>>>
>>> If the block is dedup'ed, blk_birth_phys can be before blk_birth. (The
>>> block was allocated at time A, then another reference was added to that
>>> block at a later time B.)
>>>
>>> If they are the same (e.g. as is the case for all non-dedup'ed blocks),
>>> we only store blk_birth. (I believe this is for backwards compatibility
>>> with software that doesn't understand dedup (pool version 21)).
>>>
>>> blk_birth_phys is used by the SPA, for example when resilvering devices
>>> that were temporarily offline.
>>>
>>> blk_birth is used by the DMU and DSL, for example to determine when to
>>> free a block, or what blocks should be part of a zfs send stream.
>>>
>>> --matt
>>>
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to zfs-devel+unsubscr...@zfsonlinux.org.
>>>
>>
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to zfs-devel+unsubscr...@zfsonlinux.org.
>>
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to zfs-devel+unsubscr...@zfsonlinux.org.
>
_______________________________________________
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
