Other How would you build your own NAS?

[bakul]

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.

 

[drsnx60]

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.

 

[PMc]

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.

 

[mer]

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.

 

[roper]

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.

 

[Mjölnir]

[on ZFS support vdevs on a ZVOL...] But then the "disk" isn't a disk, it is a zvol - which again wants to manage that data block within the same ARC! Now is that a separate copy or isn't it? I don't know - and I don't want to know, I just wouldn't do it.

You misunderstood me. I'm not gonna put the support vdevs on ZVOLs, because that's not recommended by the ZFS Best Practices Guide -- it could result in a deadlock, plus your explanation sounds reasonable. But I don't want to put them on fixed size partitions, because then I loose flexibility (fixed sizes). So I'd like to use a LVM, but gvinum(8) is gone in FBSD-15. Thus I'm trying to emulate a LVM "by feet": I created a bunch of partitions: 32 x 1 GB, 16 x 2 GB, 8 x 4 GB, 4 x 8 GB and 1 x 16 GB on the 2 NVMe SSDs (256 GB and 1 TB). These will be used by gvirstor(8) to provide virtual storage devices that are somewhat larger than my estimate, let's say factor 1.5 or 2. Then I have to carefully monitor their usage and add new components to the virtual devices as needed from the pool of partittions I kept in reserve.

 

[PMc]

You misunderstood me. I'm not gonna put the support vdevs on ZVOLs, because that's not recommended by the ZFS Best Practices Guide -- it could result in a deadlock, plus your explanation sounds reasonable.

Ah, fine.

But I don't want to put them on fixed size partitions, because then I loose flexibility (fixed sizes). So I'd like to use a LVM, but gvinum(8) is gone in FBSD-15. Thus I'm trying to emulate a LVM "by feet": I created a bunch of partitions: 32 x 1 GB, 16 x 2 GB, 8 x 4 GB, 4 x 8 GB and 1 x 16 GB on the 2 NVMe SSDs (256 GB and 1 TB). These will be used by gvirstor(8) to provide virtual storage devices that are somewhat larger than my estimate, let's say factor 1.5 or 2. Then I have to carefully monitor their usage and add new components to the virtual devices as needed from the pool of partittions I kept in reserve.

Hm. That sounds like You have a plan. I did retire gvinum long ago and never used gvirstor.
I for my part would go the simpler approach, start with some educated guess for fixed size partitions (better too smal than too big), then observe the behaviour to develop a better educated guess, take each single vdev offline, edit the gpart data, move the content with dd if necessary, then take it online again.
Obviousely such needs to be done with care, but I'm doing it all the time - I am using 17 distinct zpools for different purposes, because I prefer small and manageable units of data (and to power off disks that aren't currently used).

 

[bakul]

Not sure why you need LVM. I just leave aside phys mem size partition on each of the zfs disks for swap. I also try to minimize swap use (e.g. by adjusting "make -j <n>" as llvm is a hog.