mirror of
https://github.com/ewwhite/zfs-ha.git
synced 2026-05-15 14:16:09 -06:00
[GH-ISSUE #19] Host-local SLOG and L2ARC #17
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/zfs-ha#17
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mwpastore on GitHub (Jul 18, 2018).
Original GitHub issue: https://github.com/ewwhite/zfs-ha/issues/19
I'm working on a zfs-ha system design that calls for NVMe devices local to each controller for the SLOG (and possibly L2ARC). I have some strategies that I think will work for a clean failover (e.g. vdev_id aliases,
zpool addandremove), but I don't think they will work for a dirty failover. Specifically, I don't think I'll be able to import the pool on the failover host if the SLOG device(s) aren't available.I'm curious if you've given any thought to this type of configuration and if you have any suggestions, or alternatively, if you have a hard "put dual-ported SAS SSDs in your JBOD for SLOG and L2ARC and don't even think twice about it" recommendation. Thanks in advance.
@ewwhite commented on GitHub (Jul 18, 2018):
L2ARC on discrete nodes works just fine out of the box. I tend to use NVMe cards as L2ARC in the individual nodes (e.g. /dev/nvme0n1). It doesn't need to be shared.
SLOG is a different story, though. I don't have a good option for that just yet.
What are your thoughts?
@mwpastore commented on GitHub (Jul 18, 2018):
I'm trying to mentally walk through what will happen if blue crashes and leaves uncommitted writes on its SLOG. If you can bring up green with a blank, property-formatted SLOG with the same device name, I think it will work, but you will lose those writes. Maybe that's okay. But you'd need to clear blue's SLOG device before reimporting the pool on a subsequent failover, or else risk pool corruption.
Assuming all that is accurate, we just need a way to properly format the SLOG device post-failover, pre-import. Is it as simple as a
blkdiscard? Is there azpoolcommand to properly format a log device (besideszpool addandattach)? What if the SLOG is mirrored?@dkobras commented on GitHub (Aug 4, 2018):
An SLOG device has only one reason to exist: not losing (sync) writes due to a crash. In your scenario, it's ok to lose writes in this case, so why bother with an SLOG device at all? It seems to me that just setting
sync=disabledon your datasets should get you close to what you're trying to achieve, but with complexity significantly reduced.@mwpastore commented on GitHub (Aug 6, 2018):
@dkobras At the risk of being wrong on the internet, doesn't an SLOG device also speed up sync writes?
@ewwhite commented on GitHub (Aug 6, 2018):
The SLOG doesn't necessarily speed them up. It's there to ensure that those writes are on protected stable storage and acknowledged at low latency.
@ewwhite commented on GitHub (Apr 3, 2019):
Updating... I suppose you have an option to add a pre-import script that does what you need to SLOG devices.
See: https://github.com/skiselkov/stmf-ha/blob/master/heartbeat/zfs-helper and modify the script to do what you'd like for pre/post import/export.