SLOG question

[derringer]

I wondered if anyone could explain something I am seeing with a SLOG device I added recently.

First off, I have read everything on adding a log device and know why to add it and why I added it (Mac OS smb copies using 'sync'.) I did find some behavior today which conflicts with what I have read though and wanted to ask if anyone knows why.

I have a couple of different shares on the pool that is backed by a SLOG device (Optane 900p.) I get expected performance out of this when using the share I have designated as 'sync = always', and it greatly improves the sync performance. Obviously, async is still faster, so I have another share on this same pool that has 'sync=standard'. I expected the SLOG device to not be used at all when writing to this share, but it s used a bit. I see small 30Kb/s-50Kb/s writes constant to it when copying to an async share with periodic spikes to 250Kb/s. I have no problem with this, but I wondered if anyone knew why it does this from a technical perspective. Where would these writes have gone without a log device, and what are they?

thanks for any perspective,

 

[Arwen]

The manual page for zfsprops has this to say about sync on datasets;

sync=standard|always|disabled Controls the behavior of synchronous requests (e.g. fsync, O_DSYNC). standard is the POSIX-specified behavior of ensuring all synchronous requests are written to stable storage and all devices are flushed to ensure data is not cached by device controllers (this is the default). always causes every file system transaction to be written and flushed before its system call returns. This has a large performance penalty. disabled disables synchronous requests. File system transactions are only committed to stable storage periodically. This option will give the highest performance. However, it is very dangerous as ZFS would be ignoring the synchronous transaction demands of applications such as databases or NFS. Administrators should only use this option when the risks are understood.

Note that "standard" does use synchronous writes when the CLIENT requests them.

 

[derringer]

Hi, thank you for the reference. I did not give enough information though as this is just a standard samba file copy (there is no sync request from the client that I am aware of.)

The question is what function is the SLOG device performing when sync is not requested, because contrary to what I have read, it is doing *something* with these small writes on an asynchronous file write.

That is my question. I expected my log device to be inactive when asynchronous writes were being done, but it is doing something with 30-50Kb/s writes during an asynchronous copy and occasional spikes to 250Kb/s when my research expected it to be idle.

 

[winnielinnie]

The question is what function is the SLOG device performing when sync is not requested, because contrary to what I have read, it is doing *something* with these small writes on an asynchronous file write.

I expected my log device to be inactive when asynchronous writes were being done, but it is doing something with 30-50Kb/s writes during an asynchronous copy and occasional spikes to 250Kb/s when my research expected it to be idle.

Far as I know, even asynchronous writes requested from the client will use synchronous writes for metadata. That might explain the small "blips" you're seeing. (This includes SMB shares.)

 

[derringer]

Ahh, there it is, that would make sense. Metadata being sync written on an asynchronous samba file copy of a directory. Without the log device, this would have occured on the pool itself but because I have a SLOG installed, it used that instead. Learn something new every day, thank you.

Since I am gathering data and researching, I'll add another piece of information for anyone playing with SLOG devices. I am relatively certain at this point that sync writes add a decent amount of CPU overhead when being used with a SLOG. I suppose it is to be expected, but when I write to a share with sync=always and writes go through my SLOG, my CPU usage is much more demanding than when I write to the same pool under samba with sync=standard. It is either the nature of sync or the addition of the SLOG itself. I will report back once I isolate which it is.

Thanks for the feedback all.