[OmniOS-discuss] Fragmentation

[Günther Alka]

hello Richard

I can follow that the Zil does not add more fragmentation to the free 
space but is this effect relevant?
If a ZIL pre-allocates say 4G and the remaining fragmented poolsize for 
regular writes is 12T

Gea

Am 23.06.2017 um 19:30 schrieb Richard Elling:
> A slog helps fragmentation because the space for ZIL is pre-allocated based on a prediction of
> how big the write will be. The pre-allocated space includes a physical-block-sized chain block for the
> ZIL. An 8k write can allocate 12k for the ZIL entry that is freed when the txg commits. Thus, a slog
> can help decrease free space fragmentation in the pool.
>   — richard
>
>
>> On Jun 23, 2017, at 8:56 AM, Guenther Alka <alka at hfg-gmuend.de> wrote:
>>
>> A Zil or better dedicated Slog device will not help as this is not a write cache but a logdevice. Its only there to commit every written datablock and to put it onto stable storage. It is read only after a crash to redo a missing committed write.
>>
>> All writes, does not matter if sync or not, are going over the rambased write cache (per default up to 4GB). This is flushed from time to time as a large sequential write. Writes are fragmented then depending on the fragmentation of the free space.
>>
>> Gea
>>
>>
>>> To prevent it, a ZIL caching all writes (including sync ones, e.g. nfs) can help. Perhaps a DDR drive (or mirror of these) with battery and flash protection from poweroffs, so it does not wear out like flash would. In this case, how-ever random writes come, ZFS does not have to put them on media asap - so it can do larger writes later. This can also protect SSD arrays from excessive small writes and wear-out, though there a bad(ly sized) ZIL can become a bottleneck.
>>>
>>> Hope this helps,
>>> Jim
>>> --
>> _______________________________________________
>> OmniOS-discuss mailing list
>> OmniOS-discuss at lists.omniti.com
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss

--