Arch setup

[foux]

Hi there!
I've just successfully installed a test array on Archlinux using the manual install, thanks a lot!
I'm not sure if I'll migrate my main array (snapraid-btrfs) right now, as the project is still very young, but it's definitely tempting to have a realtime parity!

In anyway, thanks a lot for this project.

[qvr]

Cool!

If you do decide to use it "seriously", you might want to also install (if you didn't already) the included systemd timers for scheduled parity check and array monitoring:
https://github.com/qvr/nonraid/tree/main/tools/systemd

The udev rules I also include in the deb packages are basically optional, but they do make nmdctl status a bit faster.

The other thing to remember with Arch, or any rolling release distro, is that a new kernel release might break the driver at least temporarily, until the kernel changes have been ported over. So if that happens, you'd need to roll back to an older kernel version.

I have Arch as part of my weekly test builds to act as a sort of canary so at least I should notice if the driver no longer works with a new kernel release.

[foux]

Cool!

If you do decide to use it "seriously", you might want to also install (if you didn't already) the included systemd timers for scheduled parity check and array monitoring: https://github.com/qvr/nonraid/tree/main/tools/systemd

Yeah, I've allready installed them, just not activated

The udev rules I also include in the deb packages are basically optional, but they do make nmdctl status a bit faster.

Oh! Why is that?

The other thing to remember with Arch, or any rolling release distro, is that a new kernel release might break the driver at least temporarily, until the kernel changes have been ported over. So if that happens, you'd need to roll back to an older kernel version.

Yep, allready have the linux-lts pinned for zfs-dkms!

I have Arch as part of my weekly test builds to act as a sort of canary so at least I should notice if the driver no longer works with a new kernel release.

The next step is to create an AUR for Nonraid. I'll have to look into that.

[qvr]

The udev rules I also include in the deb packages are basically optional, but they do make nmdctl status a bit faster.

Oh! Why is that?

The rules basically cause kernel to cache blkid information when the nonraid block device (the /dev/nmdXp1 device) is created (array is started). Then when nmdctl status needs to show filesystem information, the lsblk command it uses to do that gets the information from udev cache, instead of having to actually probe the device. Normally the difference is minimal even without the blkid caching, but if the disk is busy, probing for the fs info can be very slow and then nmdctl status is also annoyingly slow.

Also, although I don't think I saw that happen when I was testing it, but without the caching it might in some scenarios cause the disk to spin up if you have them spun down.

The next step is to create an AUR for Nonraid. I'll have to look into that.

If you manage to do that, I'd be happy to at least add a link to it in the README, or have the PKGBUILD file in the project repo under contrib or something.