(At least I assume that the kernel is bringing up the Disksuite devices itself in early boot, since these machines have their root filesystem on Disksuite mirrors. I am not quite up on the black box of early Solaris boot.)

Note that the reason that the Solaris 8 boot disk must be on a simple metadevice or simple submirror is that the boot code has no concept of striping: AFAIK there is no Disksuite magic at all in the boot block.

Metadevices are configured in /etc/rcS.d/S35lvm.init (via metainit -r), just before remounting / and /usr read-write.

What seems to be going on is that Disksuite doesn't update things from the on-disk metadata state database when the kernel brings up the metadevices themselves in early boot. Instead, it defers this until you explicitly run 'metasync -r', which is normally done in /etc/init.d/lvm.sync, which is only run as part of going into runlevel 2.

Which seems sensible, given that it's foreseeable that the reason you've booted single-user could have been to change the configuration of your mirrors. Disksuite 4.2.1 mirrors or RAID5 devices cannot be detached or otherwise unconfigured while they're being sync'd (short of yanking a drive to force the resync to fail), so if the metasync were done automatically in single-user mode, you might not be able to reconfigure your devices until the useless resyncs completed.

What's wrong with waiting until you're done in multi-user mode before resyncing the mirrors? (I.e., what's the actual advantage of running /etc/init.d/lvm.sync start from single-user mode?)

--Dan Astoorian

For some reason I missed the lvm.init in /etc/rcS.d/ when I looked to see if it was run, but things make some more sense now. (I wonder if the metainit -r yanks around the kernel's idea of the root disk in the process.)

In this case we were about to break the mirror apart to defragment the filesystem 'in place', so we really wanted to be sure that the submirrors were consistent with each other before we started blowing things up.

Whoops, I missed the general answer while giving a specific one:

What's wrong with waiting until you're done in multi-user mode before resyncing the mirrors?

Because I'd expect any filesystem writes one does to make the mirrors inconsistent and require a full resync at some point. (It's possible that Disksuite is smart enough to not do that, and replicates writes to all copies of even nominally unsynced mirrors.)

Unless Disksuite is really smart, this means that I'm not actually protected by its mirroring when in single user mode, unless I specifically activate it. But I want to be protected by mirroring as much as possible, even in single-user mode when I'm installing patches or moving data around or etc; disks can fail in single-user mode as much as they can multi-user.

(In some ways disk failure in single-user mode is likely to be more severe than in multi-user, because I'm probably in single-user mode because I'm doing something especially delicate and dangerous.)

What's wrong with waiting until you're done in multi-user mode before resyncing the mirrors?

Because I'd expect any filesystem writes one does to make the mirrors inconsistent and require a full resync at some point. (It's possible that Disksuite is smart enough to not do that, and replicates writes to all copies of even nominally unsynced mirrors.)

I don't know whether it does that. My intuition suggests it would instead use the same mechanism as metaoffline / metaonline, which keeps track of the dirty regions that need to be resync'd.

The problem with Disksuite merely keeping track of the dirty region for later resyncs is that it still leaves you with a non-redundant mirror, although less of your data is exposed. I'd much rather be operating with full redundancy.