michelle at sorbs.net
Tue Apr 30 00:24:27 UTC 2019
Sent from my iPad
> On 30 Apr 2019, at 03:13, Kurt Jaeger <pi at freebsd.org> wrote:
>> I know I'm not going to be popular for this, but I'll just drop it here
> With all due respect, I think if that filesystem/server you describe
> has not kept with all those mishaps, I think it's not perfect, but
> nothing is.
The killer was the catalog of errors, where you have resolver in progress, and not one but two power failures...and just to let you know... one of the 6kva upses caught fire the other no longer recognizes AC input... so it was not your normal event. I had a good run with 8 years of running ZFS on this server.
>> Perhaps one should reconsider either:
>> 2. Defaulting to non ZFS filesystems on install.
> I had more cases of UFS being toast than ZFS until now.
I’ve toasted many, however I’ve always been able to get majority(if not all) of the data.
>> 1. Looking at tools that may be able to recover corrupt ZFS metadata, or
> Here I agree! Making tools available to dig around zombie zpools,
> which is icky in itself, would be helpful!
The one tool that I could think would be useful that is denied “because the data on disk is always right” is not a fact for zfs, but a zfs send with -AAA (like zdb) or a “zfs walk” tool that works similar to zfs send but where you can tell it to ignore the checksum errors (particularly in the structures of zfs rather than on the data itself) so you can send what’s left of your data to another box either in part or fully. Particularly as in my case all the tools tell me all the data is there and intact and it’s just the metadata that can’t be recovered/repaired.
More information about the freebsd-stable