On Mon, Oct 14, 2013 at 11:26 PM, Gaurav Mahajan <[email protected]>wrote:
> 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.? > It might work. There are several other concerns that would require an overall understanding of what you're doing. Why do you want to do that? What problem is this solving? What happens to the BP in between when it's allocated and when its written? What if the system crashes before you write the BP? It seems like the space would be leaked. What if a scrub or resilver starts after you have allocated the block but before the BP is written to disk? Could it miss scrubbing that block? --matt > > Thanks, > Gaurav. > > > > > > On Tue, Oct 15, 2013 at 11:36 AM, Matthew Ahrens <[email protected]>wrote: > >> >> >> >> On Mon, Oct 14, 2013 at 10:53 PM, Gaurav Mahajan <[email protected]>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 <[email protected]>wrote: >>> >>>> On Wed, Oct 9, 2013 at 3:35 AM, Gaurav Mahajan <[email protected]>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 [email protected]. >>>> >>> >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> >> >> To unsubscribe from this group and stop receiving emails from it, send >> an email to [email protected]. >> > > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
