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 :(. I think a fantastic idea for dealing with the DDT (and all other metadata for that matter) would be an option to put (a copy of) metadata exclusively on a SSD. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
