zfs is great. i wanted to copy my bitcoin node to external drive but didn’t want to shut it off during the copy… so i shut down my node, did a snapshot of the drive (instant), then started it again.
#zfs snapshots keep a readonly, immutable state of the drive in that moment with very little overhead. So my zaps can keep working while i clone the node (snapshots are just symlinks on the drive). Very slick.
It also has phenomenal data integrity and fault tolerance features. If you're not using them already, look into it.
ZFS is resource hungry and it really needs a ECC ram, but it is almost a miracle file system. I been using it for almost 15 years now and it is the most reliable and versatile file system I worked with.
I still prefer my FAT32. The daily defrag routine is my personal meditation time.
I know you are joking, but it is still heresy, you heathen! :-)
is running a node on an external drive & pi superior to running on a dedicated computer ? About to set a node up on a solid laptop that will just run core 24/7 but don't want to bother if an external is the way to go. Thanks for the input, I am learning
I run mine on a dedicated computer and occasionally copy it to my laptop via an 2tb m.2 drive in an enclosure. Yes a dedicated machine is ideal. pis and external drives are not super reliable.
I like ZFS best. But it requires Solaris portability layer for linux, which isn't great, and since it's not just built into linux it's easy to get into a state where ZFS isn't working.
So I moved to btrfs. Btrfs gives me LONG delay problems, sometimes more than a minute (!) before my editor will let me type again unless I'm on an SSD. So I moved my active files to an SSD. Still, I can't believe btrfs is still such shit after this many years, compared to ZFS which was really good early on even.
I've even considered leaving linux for Open Indiana. The file system is almost that important to me.
I wish I could say I'm looking forward to BCacheFS, but I predict that is going to be a nightmare of bugs given the things Linus has said about his pull requests.
How do you know it's btrfs causing the slowdown? I've been using it as my primary filesystem for years (basically since it became default on Fedora), never noticed a slowdown.
I've had other issues though, it's incredibly complex to recover when faults happen. Also, not having a feature complete fsck after all these years is bonkers!
They were kernel btrfs processes that were busy. I also got dmesg errors that were basically timeouts. I spent a lot of time with the disks thinking they were failing, but no they weren't. Also the mounts were taking so long that systemd was giving up. But after some research I upgraded to btrfs space cache v2 and that problem went away. I also spent time defragmenting and balancing and reading as much as I could on how to speed up btrfs. But eventually I just moved to SSD where it didn't really matter.
I don't know if you ever tried ZFS but I used it a lot for about a decade and it never gave me any problems (except as I mention the kernel upgrades breaking it). And I love raidz which btrfs doesn't do.
I kinda fell into the zfs on linux trap. My nas runs ubuntu but the retarded memory management requires you to declare a specific amount of what you want to use for arc, it can then not be used by the os and vice versa, whereas the freebsd implementation works much better where arc can take what it wants and if it's needed by the os it can release it.
I also run it on one of my laptops that I work on. I make snapshots every 5 minutes and zfs send them to my nas, where they will be pruned over time.
It's rather unfortunate that the implementation is so shitty on linux. I can run freebsd on my nas but i don't really want to go there with a laptop.
> the retarded memory management requires you to declare a specific amount of what you want to use for arc,
Ah yes, that sounds familiar.
Well, that sounds pretty amazing
zfs + zfsboot and life is good!
