On Wed, Feb 4, 2015 at 3:20 PM, Punit Mutha <[email protected]> wrote:
> Hello ZFS experts, > i am trying to understand zfs write codepath and space accounting related > to writes. > I have read through zfs on-disk format documents and space map blogs. > I want to follow code where blocks get allocated and where old blocks get > freed. > Looking in details of spa_sync but still my math is not turning out to be > right (in case of overwrites). > It will be great if somebody can explain the code or logic. > > > Consider a scenario when we do following steps. > > 1. 1. Zpool create > > 2. 2. Zvol create > > 3. 3. Dd if=/dev/zero of=/dev/zd0 count=100K (110 K blocks are > allocated ) > > 4. 4. Dd if=/dev/zero of=/dev/zd0 count=100K > > 5. 5. Dd if=/dev/zero of=/dev/zd0 count=100K > > For steps 4 and 5 There should not be any new allocations in back-end as > these are overwrite. > I think you mean "the total amount of allocated space should not change", because we free as much data as we allocate. > Considering Copy-on-write mechanism of zfs – there will be new allocations > for request – but they should release old blocks too. > > Is the space_map_free correct hook to walk through all old blocks that > were allocated before and being freed ? > No, that frees a spacemap object, which almost never happens. You want to trace allocation/free of blocks. Assuming you want to observe this at the SPA layer, you could trace metaslab_alloc_dva. Another confounding factor is that your dd process could dirty a block that's already dirty (from the previous dd). In this case we won't write the block twice. You can force the blocks to be allocated/written/freed between each 'dd' by running 'sync' between each 'dd'. --matt > The problem is I only can account for 109K blocks in that hook. Some of > the blocks go > missing. > > > If we are writing 100K leaf nodes, 110K blocks still seem to be too much > as 10K blocks for /indirects/ metadata / ZAP/ MOS etc ? seems to be bit > much. > > Any code details / pointers will be helpful. > > Thanks & Regards > > Punit > >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
