I’m honestly terrified to use ZFS. Roast me if you must. It has got to be the most arcane filesystem ever. I’ve tried learning it but it looks like a million obscure gotchas just waiting to fuck up your shit. Someone will post an error and people are like “ha ha you fucker yeah you didn’t shprutzle your cache vdevs sideways. Noob mistake. Oh your data is ruined btw”.
I mean look at that shit, “scrub repaired 0b with 5 errors”. I feel like Richmond looking at the server lights in IT Crowd. “Is it good that it’s doing that? Is it bad? I feel like I should be telling someone.”
i’ve had my curse zfs moment in the past even though had it in a raid z2. Later i’ve found out that was an incompatibility from the controller firmware version and the backplane of disks.
What i took out of the situation is that if zfs broke in my case any other filesystem would have broken 10 times over.
Fixed the firmware redid the raid and it has been working for 4+ years without a flaw.
haha, no, depending on your use case zfs is mostly set and forget, you just have to get a set of sane defaults, which, at least for me, is way easier and saner than stuff like btrfs. Arch wiki is a good source for that.
scrub is a command that reads data from disks and verifies checksums, it can automatically heal the corrupt data if some redundancy is available. 0 bytes repaired means nothing was repaired, 5 errors mean that there are 5 instances where the recalculated checksums of data did not match the expected values that were calculated when initially written. Normally the command would output ‘scrub repaired 0B with 0 errors’, that’s how you know that the pool is healthy.
shprutzling the cache vdevs sideways is generally required only for obscure optimizations, I’ve never seen a case where a wrong setting would lead to data loss.
The gotchas come from a single thing: the stupid CDDL licence, which is not compatible with GPL. That means that zfs is not included in linux kernel and most of the normal linux userspace filesystem stuff do not work with zfs.
Also, keep in mind that zfs is generally almost impossible to fuck up, what I’ve done here is a result of extreme dedication and like 8 years of experience.
Just so I understand, since I was looking into using ZFS for my storage before hard drives went up by like 400%: you set up things in an obtuse way and you got a failure that can’t be recovered from?
I somewhat wrapped my head around how ZFS data storage itself works, and was feeling relatively confident that it’s what I’d use.
the problem here does not originate in zfs, this is a hardware failure due to a poorly supported SoC (vendor says PCIe works ‘normally’ since kernel 7.1, this system ran 6.19) and bad electricity supply
I’m honestly terrified to use ZFS. Roast me if you must. It has got to be the most arcane filesystem ever. I’ve tried learning it but it looks like a million obscure gotchas just waiting to fuck up your shit. Someone will post an error and people are like “ha ha you fucker yeah you didn’t shprutzle your cache vdevs sideways. Noob mistake. Oh your data is ruined btw”.
I mean look at that shit, “scrub repaired 0b with 5 errors”. I feel like Richmond looking at the server lights in IT Crowd. “Is it good that it’s doing that? Is it bad? I feel like I should be telling someone.”
i’ve had my curse zfs moment in the past even though had it in a raid z2. Later i’ve found out that was an incompatibility from the controller firmware version and the backplane of disks.
What i took out of the situation is that if zfs broke in my case any other filesystem would have broken 10 times over.
Fixed the firmware redid the raid and it has been working for 4+ years without a flaw.
haha, no, depending on your use case zfs is mostly set and forget, you just have to get a set of sane defaults, which, at least for me, is way easier and saner than stuff like btrfs. Arch wiki is a good source for that.
scrub is a command that reads data from disks and verifies checksums, it can automatically heal the corrupt data if some redundancy is available. 0 bytes repaired means nothing was repaired, 5 errors mean that there are 5 instances where the recalculated checksums of data did not match the expected values that were calculated when initially written. Normally the command would output ‘scrub repaired 0B with 0 errors’, that’s how you know that the pool is healthy.
shprutzling the cache vdevs sideways is generally required only for obscure optimizations, I’ve never seen a case where a wrong setting would lead to data loss.
The gotchas come from a single thing: the stupid CDDL licence, which is not compatible with GPL. That means that zfs is not included in linux kernel and most of the normal linux userspace filesystem stuff do not work with zfs.
Also, keep in mind that zfs is generally almost impossible to fuck up, what I’ve done here is a result of extreme dedication and like 8 years of experience.
Just so I understand, since I was looking into using ZFS for my storage before hard drives went up by like 400%: you set up things in an obtuse way and you got a failure that can’t be recovered from?
I somewhat wrapped my head around how ZFS data storage itself works, and was feeling relatively confident that it’s what I’d use.
the problem here does not originate in zfs, this is a hardware failure due to a poorly supported SoC (vendor says PCIe works ‘normally’ since kernel 7.1, this system ran 6.19) and bad electricity supply