I feel that, while that's true and valid, it also kind of misses the point?
What I'm wondering is, are there simple enhancements that would be
beneficial in that area, or provide useful internal data.
It seems plausible that if a configurable in space map block size helps,
perhaps a
It is a sub-feature of the allocation classes you mentioned in your
first email.
One of the options is to have an vdev dedicated to housing the DDT.
On 2019-07-07 11:03, Richard Elling wrote:
> Yes, from the ZoL zpool man page:
> A device dedicated solely for deduplication tables.
>
> --
Yes, from the ZoL zpool man page:
A device dedicated solely for deduplication tables.
-- richard
> On Jul 7, 2019, at 5:41 AM, Stilez wrote:
>
> "Dedup special class"?
>
>> On 6 July 2019 16:24:27 Richard Elling
>> wrote:
>>
>>
>>> On Jul 5, 2019, at 9:11 PM, Stilez wrote:
>>>
>>>
"Dedup special class"?
On 6 July 2019 16:24:27 Richard Elling
wrote:
On Jul 5, 2019, at 9:11 PM, Stilez wrote:
I'm one of many end-users with highly dedupable pools held back by DDT and
spacemap RW inefficiencies. There's been discussion and presentations -
Matt Ahrens' talk at BSDCan
