Other How would you build your own NAS?

ZIL should also be possible to get lost and be recovered, or renewed, only there is a bit more complaints on the path.
ZIL (intent log) is part of the ZFS protocol. Perhaps you are thinking of a SLOG (separate log) device? If a SLOG is used, it takes over the intent log function (without it the same zpool is used). Losing a SLOG device at an inopportune time can result in data loss.
 
ZIL (intent log) is part of the ZFS protocol. Perhaps you are thinking of a SLOG (separate log) device? If a SLOG is used, it takes over the intent log function (without it the same zpool is used). Losing a SLOG device at an inopportune time can result in data loss.
which is why it needs to be on a mirrored device , so that you dont loose the ZIL.
The SLOG ZIL on SSDś or NVME, is useful if the main ZPOOL is based on HDDs.
If the main ZPOOL is based on SSD/NVME there are really no speed adavantage in having a separet SLOG ZIL.
 
ZIL (intent log) is part of the ZFS protocol. Perhaps you are thinking of a SLOG (separate log) device?
I never contemplated much about the difference. As long as there is no separate device, the thing is handled internally. Of administrative concern is it only when there is a separate device.

If a SLOG is used, it takes over the intent log function (without it the same zpool is used). Losing a SLOG device at an inopportune time can result in data loss.
Yes, that's right. But it should be possible (during a planned maintenance) to bring the pool into a synchronized state where no data is pending in the ZIL. And if then the SLOG gets lost, it should be possible to recreate it without data loss.
Anyway, otherwise it should always be possible to enlarge the (mirrored) SLOG by the usual means of extendsz.
 
I think one needs to keep in mind the access/usage patterns and what you need to optimize. Is the NAS going to be used for mostly "sharing" as in saved videos shared to other devices? That's mostly read access. Is it going to be database where it's mostly write access?
That read vs write I think is important as it relates to ZIL, SLOG, L2ARC.
Think about NAS being source for video: read source push to network. What's the bottle neck? Read typically winds up device to ARC maybe demoted to L2ARC to network socket.
Database pushes. Writes that may have synchronous requirements which I think feeds into things like ZIL and SLOG.

So just like every performance tweak in history (automobile engines in particular): what is most important in the nominal use case. Don't optimize for the wrong thing.
 
what is most important in the nominal use case
I think this is very true. I've tinkered with NAS a bit. I've one older Intel atom box that's raid-z1 mirrored ZIL and read cache ssd and another somewhat newer but now five year old AMD Ryzen box which is without ZIL or SLOG drives in a mirrored configuration. While the newer cpu is faster the perfomance at everyday file operations, I can't really tell any difference. The Atom motherboard failed recently, as they were prone to do but by only rebooting about once a year it lasted eleven. It was one of those Asrock Rack C2550d4i boards, and I read the problem was solved in boards produced after 2018 so I snatched up two of the C2750d4i boards off ebay this year. In for the long haul on that one I am. I've a write-up or two about building these, along with some history of older ZFS adventures with eSata cables to an external DAS array and even a cluster of external 1TB hard drives rigged up via a USB hub. I refer back to it sometimes as I forget things. The next zpool expansion will have the two spinning around 100TB. I don't need it, but I have the hoarding instinct and this isn't messy.
 
  • Like
Reactions: mer
Back
Top