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 <a...@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@lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
