do you ever get a new shiny thing and it looks like it works very nice and coherently and then you dig a bit deeper and realize that it is just a bunch of semi-broken shit held together by glue and duct tape? that’s the state of android, that is nicely obscured on pixels by google customizations
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.
I’ve seen a calculation somewhere for drive speed, size and scrub frequency where optimal number of extra drives was calculated. On fast storage and with weekly scrubs one extra drive should be mostly fine.
My philosophy is any raid is not really a data contingency solution - it just saves some time when the drive fails.
that’s no fun. also, it turned out that this is not a disk error, the zfs metadata got corrupted and now I get a panic when trying to mount this.
my achievement here is that this is a proper raidz setup with multiple disks and ecc ram
also, machines wipe themselves at each boot! service state data is distributed via zfs send! zfs that actually works!
Profiles are nice and all, but remember, that there are still ways to track you across profiles (serious determination required), like the network stack being mostly shared. Here’s the thread.
If you truly need isolated apps, consider getting multiple phones. I personally have three devices for this. For example, my main device (where I actually use the web browser and which is connected to my private network) runs only a limited set of foss apps. This will solve the alarms issue as well as this device has only one profile.
I’ve been hosting grist for a while and it is quite nice. Wasn’t able to move all the stuff from classic spreadsheets though
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