Mounting root...
Dan Nelson
dnelson at allantgroup.com
Mon Aug 23 13:01:59 PDT 2004
In the last episode (Aug 23), Pawel Jakub Dawidek said:
> On Mon, Aug 23, 2004 at 11:46:12AM -0400, John Baldwin wrote:
> +> Why not have mirror create the provider instantly in an degraded
> +> state as soon as one disk shows up and then change from degraded
> +> back to full when the second disk finally arrives? Isn't this the
> +> same case as someone jerking the disk out at run time and then
> +> shoving it (or a new one) back in without rebooting?
>
> If it will be started in degraded mode, it can be mounted and
> modified before next components arrive, so there will be a need to
> rebuild them.
There are a couple of cases here:
1. The mirror was cleanly closed on shutdown, in which case you can
allow write access and simply sync the changes onto the other disk
whenever it decides to show up.
2. The mirror is dirty and the other disk is never going to show up,
since it has failed. You need to allow write access for the system
to boot and a replacement disk to be added (possibly hot-swapped
in).
3. The mirror is dirty, but the other disk is around somewhere (USB
disk with its cable kicked out, maybe). In this case you don't know
if the half you have is current, but you have to allow at least read
access for the system to boot up. If you allow write access before
the other half is found you risk corrupting the filesystem if it
turns out the other mirror has changes that conflict with yours and
you don't resync them correctly.
How about maybe blocking on the initial access to a degraded mirror for
5 (just a guess) seconds to see if the other half shows up? If it
doesn't, assume it's never showing up and use what you have. When the
other disk arrives, sync your changes over to it. If geom_mirror keeps
an on-disk bitmap of dirty blocks for fast resyncs, copy your data over
the other mirror's dirty blocks. You'll lose whatever changes were
made to that disk, but at least the filesystem will be consistent.
--
Dan Nelson
dnelson at allantgroup.com
More information about the freebsd-arch
mailing list