3 ms·
Just today, I finally had the hardware in place to fire up my 10-year-old ZFS array. It used to be my daily driver, but three moves across country and small li
by watersb 4y ago
Just today, I finally had the hardware in place to fire up my 10-year-old ZFS array.
It used to be my daily driver, but three moves across country and small living spaces pushed this storage box down in urgency; I regressed back to my old bad habits of haphazard disks and flash drives and usb "thumb" drives... all over...
Anyhow, tried to import the ZFS pool, crashed ZFS, caused a kernel panic. Dang.
Switched to a recent FreeBSD distribution, same crash.
I'm pulling together the various methods of recovery from folks who've seen this type of failure, and all will be well. (Or if not, I've got at least one good snapshot up on Backblaze.)
But user space for something like this sounds like the perfect fit. ZFS already subsumes functions from device driver to blocks and files manager, on up to volumes and snapshots-- the whole storage stack. Those user-facing aspects of storage and volume management could reasonably be taken as a user space process tree, where a crash wouldn't bring down your entire server.
Heck, to triage my problem, it's suggested to re-run the zpool import with other options. If I could iterate and converge on a operational set of recovery steps, without taking my entire server out and back up from cold boot, yeah that would be great!
- teddyh 4y agoYou’re essentially re-discovering the principles of GNU Hurd.
- deleted 4y ago[deleted]