On Aug 1, 2012, at 8:30 AM, Nigel W wrote: > On Wed, Aug 1, 2012 at 8:33 AM, Sašo Kiselkov <skiselkov...@gmail.com> wrote: >> On 08/01/2012 04:14 PM, Jim Klimov wrote: >>> chances are that >>> some blocks of userdata might be more popular than a DDT block and >>> would push it out of L2ARC as well... >> >> Which is why I plan on investigating implementing some tunable policy >> module that would allow the administrator to get around this problem. >> E.g. administrator dedicates 50G of ARC space to metadata (which >> includes the DDT) or only the DDT specifically. My idea is still a bit >> fuzzy, but it revolves primarily around allocating and policing min and >> max quotas for a given ARC entry type. I'll start a separate discussion >> thread for this later on once I have everything organized in my mind >> about where I plan on taking this. >> > > Yes. +1 > > The L2ARC as is it currently implemented is not terribly useful for > storing the DDT in anyway because each DDT entry is 376 bytes but the > L2ARC reference is 176 bytes, so best case you get just over double > the DDT entries in the L2ARC as what you would get into the ARC but > then you have also have no ARC left for anything else :(.
You are making the assumption that each DDT table entry consumes one metadata update. This is not the case. The DDT is implemented as an AVL tree. As per other metadata in ZFS, the data is compressed. So you cannot make a direct correlation between the DDT entry size and the affect on the stored metadata on disk sectors. -- richard -- ZFS Performance and Training richard.ell...@richardelling.com +1-760-896-4422
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
