ZIL location on pool with special device but no SLOG device?

[sgsunder]

I have pool structured using an 18 TB mirror as a primary vdev, and a 500GB mirror as a special vdev.

I also have the following settings for the dataset on which I run postgres:

$ zfs get recordsize,special_small_blocks tank/database
NAME           PROPERTY              VALUE                 SOURCE
tank/database  recordsize            16K                   local
tank/database  special_small_blocks  16K                   local

so all writes should ultimately end up on the special device. However I'm not entirely sure that the ZIL writes are also done on the special device. The only information I could find online is here, but it doesn't really give a conclusive answer.

Does anyone have any more information on this?

[rincebrain]

I don't think there's currently any logic to prefer something over another to be a ZIL block storage location.

There's a reasonable argument to be made for preferring special vdevs for that if they exist, but I don't think there's anything in the code that currently does that.

[sgsunder]

Forgot to mention that I opened #15881 as a feature request

[scineram]

Sure, but is there much reason for it to not try spa_special_class before falling through to spa_normal_class? I don't immediately see one, though it's possible I'm overlooking something.

That's not gonna help if the complaint is the ZIL is on the normal vdevs in embedded log metaslabs.

[amotin]

Sure, but is there much reason for it to not try spa_special_class before falling through to spa_normal_class?

As I have just written on other ticket, not every special vdev, that may be perfect for metadata or small blocks, is good or even acceptable for SLOG role.
Also to not grow fragmentation of special vdevs we would better implement some sort of spa_special_embedded_log_class(), similar to spa_embedded_log_class() for normal vdevs.

[rincebrain]

Sure, I'm not suggesting we don't have some nice handling to avoid similar issues to why embedded_log exists, and I agree there are plenty of SSDs that have terrible latency (tail or otherwise) where this would be a bad idea, so great, have a tunable for the pool (per-top-level-vdev would make more sense, potentially, but then it becomes much harder to discover if we expect people to have to change it more often...)

Then there's a conversation about the default, because lots of people don't change the defaults, and I don't think it'd be unreasonable to include the functionality and then have a release note of "if you see performance issues after this, change this setting, but for many people this is an improvement, so the default was chosen that way".

But the premise doesn't seem unreasonable, even if there's discussion to be had about the best defaults and way to expose it, yes?

[amotin]

But the premise doesn't seem unreasonable, even if there's discussion to be had about the best defaults and way to expose it, yes?

If the question is whether it can be useful in some cases to put ZIL on special vdev, then I think it would be a good features. As default -- may be, but not sure. Always -- I'd say no.