On Thu, Aug 30, 2012 at 9:08 PM, Nomen Nescio <nob...@dizum.com> wrote:
> In this specific use case I would rather have a system that's still bootable
> and runs as best it can
That's what would happen if the corruption happens on part of the disk
(e.g. bad sector).
> than an unbootable system that has detected an
> integrity problem especially at this point in ZFS's life. If ZFS would not
> panic the kernel and give the option to fail or mark file(s) bad,
You'd be unable to access that particular file. Access to other files
would still be fine.
> would be very annoying if ZFS barfed on a technicality and I had to
> reinstall the whole OS because of a kernel panic and an unbootable system.
It shouldn't do that.
Plus, if you look around a bit, you'll find some tutorials to back up
the entire OS using zfs send-receive. So even if for some reason the
OS becomes unbootable (e.g. blocks on some critical file is corrupted,
which would cause panic/crash no matter what filesystem you use), the
"reinstall" process is basically just a zfs send-receive plus
installing the bootloader, so it can be VERY fast.
This is what I do on linux (ubuntu + zfsonlinux). Two notebooks and
one USB disk (which function as rescue/backup disk) basically store
the same copy of the OS dataset, with very small variations (only four
files) for each environment. I can even update one of them and copy
the update result (using incremental send) to the others, making sure
I will always have the same working environment no matter which
notebook I'm working on.
zfs-discuss mailing list