New to TrueNas - Some questions before I get started.

[panzerscope]

Shouldn't you be adding it to a pool, not creating its own pool

Ahh yes, that is my error. Good shout! Thanks for pointing that out.

 

[panzerscope]

A query, so how would I go about checking that the SLOG is essentially doing its job. I can see that the Log drive is online within my main pool. I just transferred some data, approximately 10GB+ to my main pool and then checked the reporting section to see the metrics on the log drive and notice there is nothing recorded ?

Here is a screenshot with my Log drive being online in the pool.

During my file transfer I noted the metrics as per the below screenshot

Any advice greatly received :) I note that the SLOG is for Sync Writes, but shouldn't I see some device activity ?

 

[Etorix]

No sync writes = no SLOG activity.

 

[NugentS]

zpool iostat -v 1
If you are doing sync writes then you should see the SLOG in operation

 

[panzerscope]

zpool iostat -v 1
If you are doing sync writes then you should see the SLOG in operation

Thanks! I will keep an eye on it :)

 

[mark1301]

Not 100% sure but I believe the SLOG/Log should be 'linked/tied' to a specific pool. Is your's set up this way?

 

[Ericloewe]

Not 100% sure but I believe the SLOG/Log should be 'linked/tied' to a specific pool. Is your's set up this way?

SLOG is just a special vdev type. The practical implication of that, as relates to your question, is that an SLOG device can only be part of a single pool. There's no "linking or tying" beyond adding an SLOG vdev to the desired pool.
In this case, that is resolved as of #22 as evidenced by the SLOG vdev showing up as a top-level device of pool Tank in the GUI, which closely mirrors the output from zpool status.

 

[mark1301]

SLOG is just a special vdev type. The practical implication of that, as relates to your question, is that an SLOG device can only be part of a single pool. There's no "linking or tying" beyond adding an SLOG vdev to the desired pool.
In this case, that is resolved as of #22 as evidenced by the SLOG vdev showing up as a top-level device of pool Tank in the GUI, which closely mirrors the output from zpool status.

I'd known there was a 'reason' for having a SLOG but didn't know if he had it tied to the specific pool or not. Out of curiosity - can't you also create different SLOGs for different pools, as long as you have the disks for it? For instance if you had a 'heavy' VM platform you'd want 1 for it, and perhaps another for a 'lighter' pool that way in case of a crash - you had all the data for both pools if needed to rebuild?

 

[Ericloewe]

I'd known there was a 'reason' for having a SLOG but didn't know if he had it tied to the specific pool or not. Out of curiosity - can't you also create different SLOGs for different pools, as long as you have the disks for it? For instance if you had a 'heavy' VM platform you'd want 1 for it, and perhaps another for a 'lighter' pool that way in case of a crash - you had all the data for both pools if needed to rebuild?

Some confusion there:

• It's not necessarily about physical disks, partitions can also work if the disk is fast enough.
• Yes, there can be multiple SLOG devices for multiple pools.
• The presence of an SLOG doesn't directly impact data safety. It's a Separate LOG device, but all pools have a ZIL. The point of SLOG is just to make sync writes faster than is possible with the on-pool ZIL.
• If the SLOG dies or if writes are async, you don't lose the pool, just up to a few seconds of transactions.

 

[Arwen]

One other note about SLOGs. They are basically write only devices, EXCEPT during a crash / power failure that had outstanding writes still on SLOG but not in pool. Then, they are useful.

And to be crystal clear, ZFS was was specifically designed with crashes / power failures in mind. Pool corruption is not going to happen unless their is other hardware at fault. (Like disk failure.) Data blocks are written as "copy on write", so the prior data / metadata, (aka directory info), remains intact, even after the very top level pointers are changed to the new data. (Of course, after that, the old data is then free to be over-written.)

In the even of a crash or power failure, any data in flight is either going to be stored correctly, or lost. And any file system can loose data in flight.