[OmniOS-discuss] ZFS Slog - force all writes to go to Slog

Rune Tipsmark rt at steait.net
Thu Feb 19 02:09:36 UTC 2015


________________________________
From: Richard Elling <richard.elling at richardelling.com>
Sent: Thursday, February 19, 2015 1:27 AM
To: Rune Tipsmark
Cc: omnios-discuss at lists.omniti.com
Subject: Re: [OmniOS-discuss] ZFS Slog - force all writes to go to Slog


On Feb 18, 2015, at 12:04 PM, Rune Tipsmark <rt at steait.net<mailto:rt at steait.net>> wrote:


hi all,



I found an entry about zil_slog_limit here: http://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSWritesAndZILII

it basically explains how writes larger than 1MB per default hits the main pool rather than my Slog device - I could not find much further information nor the equivalent setting in OmniOS. I also read http://nex7.blogspot.ca/2013/04/zfs-intent-log.html but it didn't truly help me understand just how I can force every written byte to my ZFS box to go the ZIL regardless of size, I never ever want anything to go directly to my man pool ever.


"never ever want anything to go to main pool" is not feasible. The ZIL is a ZFS Intent Log
http://en.wikipedia.org/wiki/Intent_log and, unless you overwrite prior to txg commit, everything
ends up in the main pool.

>> yeah I know, I meant everything needs to go thru the ZIL before hitting the main pool...

I have sync=always and disabled write back cache on my volume based LU's.



Testing with zfs_txg_timeout set to 30 or 60 seconds seems to make no difference if I write large files to my LU's - I don't seem the write speed being consistent with the performance of the Slog devices. It looks as if it goes straight to disk and hence the performance is less than great to say the least.


Ultimately, the pool must be able to sustain the workload, or it will have to throttle.

>> it should be OK to take in some hundreds MB/sec (11 SAS mirrors each can do ~150MB/Sec sequential)
The comment for zil_slog_limit is concise:
/*
 * Use the slog as long as the logbias is 'latency' and the current commit size
 * doesn't exceed the limit or the total list size doesn't exceed its limit.
 * Limit checking is disabled by setting zil_slog_limit to UINT64_MAX.
 */
uint64_t zil_slog_limit = (1024 * 1024);
uint64_t zil_slog_list_limit = (1024 * 1024 * 200);

and you can change this on the fly using mdb to experiment.

>> how do I do this? I could not find any property matching....



How do I ensure 100% that all writes always goes to my Slog devices - no exceptions.


The question really isn't "how" the question is "why"? Now that you know what an
Intent Log is, and how the performance of the pool is your ultimate limit, perhaps you
can explain what you are really trying to accomplish?

>> consistent fast write speeds at all times rather than yoyo write speeds... I get fine benchmarks but rather less fine file copy performance... and I never ever see disks being particular busy during file copy tests....
 -- richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20150219/89c94321/attachment-0001.html>


More information about the OmniOS-discuss mailing list