Correct way to remove SLOG?

[Evan Richardson]

I have a mirrored SLOG:

NAME STATE READ WRITE CKS
lyra ONLINE 0 0
raidz2-0 ONLINE 0 0
gptid/1858e4c0-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/1999d2c7-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/1acf1207-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/1bfe8147-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/1d31c42e-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/1e657560-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
raidz2-1 ONLINE 0 0
gptid/1f999395-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/20ce4760-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/21f4758d-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/2319c535-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/24404be5-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/25716505-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
logs
mirror-2 ONLINE 0 0
gptid/a07a9aac-f225-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/a4f6147c-f225-11e5-bbb9-0cc47ab3caac ONLINE 0 0


I originally added a pair of samsung 850 Evo's in a mirror, thinking it would help my home media server, before I realized it sits pretty much idle (watching zilstat):

[root@vega] /mnt/lyra/Images# zilstat -M
N-MB N-MB/s N-Max-Rate B-MB B-MB/s B-Max-Rate ops <=4kB 4-32kB >=32kB
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 25 0 0 25
0 0 0 0 0 0 11 0 0 11
0 0 0 1 1 1 12 0 0 12
0 0 0 2 2 2 28 0 7 21
0 0 0 0 0 0 3 0 0 3
0 0 0 0 0 0 8 0 0 8
0 0 0 0 0 0 10 0 0 10


So i want to remove it... I'm on the latest version of freenas 9.10 something, so am I correct in thinking that I can just do zpool remove lyra mirror-2? Lookign at this post:
https://forums.freenas.org/index.ph...remove-an-ssd-cache-drive-from-a-zpool.22484/

It seems I can, but want to make sure before I run something potentially dangerous against my pool. Thanks!

 

[ethereal]

zpool remove pool device ...

Removes the specified device from the pool. This command currently
only supports removing hot spares, cache, and log devices. A mirrored
log device can be removed by specifying the top-level mirror for the
log. Non-log devices that are part of a mirrored configuration can be
removed using the "zpool detach" command. Non-redundant and raidz
devices cannot be removed from a pool.

Removing a Mirrored Log    Device

       The following command removes the mirrored log device mirror-2.

       Given this configuration:

        pool: tank
       state: ONLINE
       scrub: none requested
      config:

          NAME          STATE    READ WRITE CKSUM
          tank          ONLINE       0     0     0
            mirror-0  ONLINE       0     0     0
             da0  ONLINE       0     0     0
             da1  ONLINE       0     0     0
            mirror-1  ONLINE       0     0     0
             da2  ONLINE       0     0     0
             da3  ONLINE       0     0     0
          logs
            mirror-2  ONLINE       0     0     0
             da4  ONLINE       0     0     0
             da5  ONLINE       0     0     0

       The command to remove the mirrored log mirror-2 is:

     # zpool remove    tank mirror-2

 

[jgreco]

I have a mirrored SLOG:

NAME STATE READ WRITE CKS
lyra ONLINE 0 0
raidz2-0 ONLINE 0 0
gptid/1858e4c0-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/1999d2c7-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/1acf1207-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/1bfe8147-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/1d31c42e-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/1e657560-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
raidz2-1 ONLINE 0 0
gptid/1f999395-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/20ce4760-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/21f4758d-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/2319c535-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/24404be5-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/25716505-f224-11e5-bbb9-0cc47ab3caac ONLINE 0 0
logs
mirror-2 ONLINE 0 0
gptid/a07a9aac-f225-11e5-bbb9-0cc47ab3caac ONLINE 0 0
gptid/a4f6147c-f225-11e5-bbb9-0cc47ab3caac ONLINE 0 0


I originally added a pair of samsung 850 Evo's in a mirror, thinking it would help my home media server, before I realized it sits pretty much idle (watching zilstat):

[root@vega] /mnt/lyra/Images# zilstat -M
N-MB N-MB/s N-Max-Rate B-MB B-MB/s B-Max-Rate ops <=4kB 4-32kB >=32kB
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 25 0 0 25
0 0 0 0 0 0 11 0 0 11
0 0 0 1 1 1 12 0 0 12
0 0 0 2 2 2 28 0 7 21
0 0 0 0 0 0 3 0 0 3
0 0 0 0 0 0 8 0 0 8
0 0 0 0 0 0 10 0 0 10


So i want to remove it... I'm on the latest version of freenas 9.10 something, so am I correct in thinking that I can just do zpool remove lyra mirror-2? Lookign at this post:
https://forums.freenas.org/index.ph...remove-an-ssd-cache-drive-from-a-zpool.22484/

It seems I can, but want to make sure before I run something potentially dangerous against my pool. Thanks!

First, why would you have added a pair of Samsung 850 Evo's? Those devices are totally unsuitable to being a SLOG. You're better off just not adding a SLOG than adding a crappy SLOG. You wouldn't put diesel gasoline in your unleaded vehicle, would you?

Second, while you can potentially do this via the CLI, you shouldn't. FreeNAS will not be aware of the change.

Go to Storage->Volumes->View Volumes. Select the top level volume (lyra). At the bottom, "Volume Status". Brings up a view of your volume. Click on the device you want to modify, under cache, stripe, $(devicename). Click "Remove" at the bottom.

 

[Evan Richardson]

First, why would you have added a pair of Samsung 850 Evo's? Those devices are totally unsuitable to being a SLOG. You're better off just not adding a SLOG than adding a crappy SLOG. You wouldn't put diesel gasoline in your unleaded vehicle, would you?

Second, while you can potentially do this via the CLI, you shouldn't. FreeNAS will not be aware of the change.

Go to Storage->Volumes->View Volumes. Select the top level volume (lyra). At the bottom, "Volume Status". Brings up a view of your volume. Click on the device you want to modify, under cache, stripe, $(devicename). Click "Remove" at the bottom.

What's wrong with 850 evo's? the read/write/random performance is decent on them.

 

[jgreco]

What's wrong with 850 evo's? the read/write/random performance is decent on them.

Do you understand what the point of a SLOG device is? It is to provide a method for the system to guarantee the completion of sync writes in the event of a power failure, etc. The 850 EVO lacks power loss protection, so if power is lost, some writes to your SLOG are lost, which trashes the whole concept behind the SLOG.

If it isn't providing you the security it was designed to intend, then it is potentially slowing down your pool, maybe significantly, for no positive benefit.

https://forums.freenas.org/index.php?threads/some-insights-into-slog-zil-with-zfs-on-freenas.13633/

 

[ethereal]

apart from that - it's great

 

[Evan Richardson]

Do you understand what the point of a SLOG device is? It is to provide a method for the system to guarantee the completion of sync writes in the event of a power failure, etc. The 850 EVO lacks power loss protection, so if power is lost, some writes to your SLOG are lost, which trashes the whole concept behind the SLOG.

If it isn't providing you the security it was designed to intend, then it is potentially slowing down your pool, maybe significantly, for no positive benefit.

https://forums.freenas.org/index.php?threads/some-insights-into-slog-zil-with-zfs-on-freenas.13633/

I work in DC operations for a storage company that uses ZFS based storage for our customers offsite data, so yes I understand what a SLOG is for. While the 850's do not have a BBU, the 1000W UPS attached directly to this box does, which is good enough for me considering this sits in my garage and the only person who touches it, is me. That being said, I ended up getting an intel DC S3500 240GB drive which has proven to be much better at handling the writes coming out of ESX then the 850's were. The 850's did work, but they were much slower (1/4) than the S3500 is.

The 850's are fantastic drives by the way, but not for random workloads it seems.

 

[depasseg]

While the 850's do not have a BBU, the 1000W UPS attached directly to this box does, which is good enough for me considering this sits in my garage and the only person who touches it, is me.

For anyone else reading this in the future, please realize that a computer on a UPS is not adequate power protection for a SLOG. True, it reduces power off events due to grid failure, but being on a UPS has no effect in the case of a hard power reset (like if the server is unresponsive and you have to press and hold the power button to force power off), in which case you just lost everything in your write cache which ZFS though was safely written to stable storage..

 

[fta]

in which case you just lost everything in your write cache which ZFS though was safely written to stable storage..

So what? In the unlikely event that happens, I might get a corrupted VM or corrupted app data. The pool itself will be fine.

 

[jgreco]

So what? In the unlikely event that happens, I might get a corrupted VM or corrupted app data. The pool itself will be fine.

Then you should just remove the SLOG and not worry about it. SLOGs are for people for whom a corrupt VM is unacceptable. Adding an unsuitable SLOG device to ZFS does nothing good, and introduces a severe performance penalty for no value received.

 

[depasseg]

So what? In the unlikely event that happens, I might get a corrupted VM or corrupted app data. The pool itself will be fine.

My point was to inform others. You seem to be aware of and OK with possible data loss, which is fine, but others might not be aware of that possibility.

 

[fta]

Then you should just remove the SLOG and not worry about it. SLOGs are for people for whom a corrupt VM is unacceptable.

The ZIL if for people for whom a corrupt VM is unacceptable. An SLOG is for people who want the ZIL to be fast (or faster than the ZIL on the pool).

Adding an unsuitable SLOG device to ZFS does nothing good, and introduces a severe performance penalty for no value received.

It is not black or white. SSDs without power loss protection can still provide good SLOG performance.

 

[fta]

My point was to inform others. You seem to be aware of and OK with possible data loss, which is fine, but others might not be aware of that possibility.

Yep, you're right. It was good information.

 

[depasseg]

The ZIL if for people for whom a corrupt VM is unacceptable. An SLOG is for people who want the ZIL to be fast (or faster than the ZIL on the pool).



It is not black or white. SSDs without power loss protection can still provide good SLOG performance.

The zil is a part of zfs. No matter what. The choice to use sync writes is what slows things down, because in that case writes must be made to non volatile storage, which by default would be on the pool. A slog can be used as that non volatile storage and that is where the need for power loss protection for that specific SSD device comes in.

 

[fta]

The zil is a part of zfs. No matter what. The choice to use sync writes is what slows things down, because in that case writes must be made to non volatile storage, which by default would be on the pool. A slog can be used as that non volatile storage and that is where the need for power loss protection for that specific SSD device comes in.

This has nothing to do with what he said. He said an unsuitable device, which you guys deem as not having power loss protection, "does nothing good, and introduces a severe performance penalty for no value received." This is not true. There are plenty of SSDs (probably most) without power loss protection that will definitely add value and give you a performance benefit if you're using sync=always. You will, of course, have more possible failure scenarios that we've already discussed.

 

[depasseg]

True, some SSDs do provide greatly increased performance, regardless of the power protection. But if someone isn't worried about power protection, then skip the slog and don't use sync writes. In that case RAM will be used which is even faster than SSD.

 

[fta]

True, some SSDs do provide greatly increased performance, regardless of the power protection. But if someone isn't worried about power protection, then skip the slog and don't use sync writes. In that case RAM will be used which is even faster than SSD. :)

This is a good point, but also a black or white fallacy. You're not guaranteed to lose data if the SSD loses power, for example. The probability you'll lose data with no sync writes is much greater.

 

[depasseg]

True

 

[jgreco]

This is a good point, but also a black or white fallacy. You're not guaranteed to lose data if the SSD loses power, for example. The probability you'll lose data with no sync writes is much greater.

So you're talking about the difference between rolling back to the last completed transaction group during pool import versus losing an unknown amount of transactional data.

Hint: Both are really bad if it matters at all, so neither option is "better."

This reminds me of a discussion I had with one of my first girlfriends, who didn't want to wear a seat belt in the car because someone had told her that the seat belt *could* kill her in some cases. Never mind that it saves you most of the time, or that the air bag inflating without the cooperating benefit of a seat belt is much more harmful... people believe what they want to.

So believe what you want to. There are probably edge cases where a non-power-loss protected SSD could buy you some benefit, but I'm going to wrap this up by pointing at

The OpenZFS Hardware Wiki which says "Flash drives used for top-level vdevs or SLOG devices should have power failure protection"

plus all the other various authorities who indicate that this is the correct way to go.