On 02/08/13 11:26, Joel Sing wrote:
On Sat, 9 Feb 2013, Jiri B wrote:
On Sat, Feb 09, 2013 at 02:56:47AM +1100, Joel Sing wrote:
While stacked softraid volumes generally work, they are not officially
supported (for a variety of reasons). The problem that you mention above
is due to the way that softraid volumes are shutdown - the shutdown order
is approximately the same as the order they are created. In your case
this means that sd3 gets shutdown before sd4, hence sd4 is unable to
write metadata to sd3. For the time being, in order to avoid the issue
you should disassemble the CRYPTO volume (sd4) before the RAID 1 volume
(sd3).
Shit, I forgot to mention that I already gave that a whirl by putting:
umount -f /st3 <-- the mount point of the crypto volume
in /etc/rc.shutdown. It makes no difference; I still get that
warning/error.
I also tried:
umount -f 6c6e53ab843ef6c8.a <-- the DUID of the crypto volume
and, curiously, it says that it's not currently mounted. (Yet that's
exactly how I mount it with bioctl in rc.securelevel, where it prompts
me for the password.) I've also tried doing it by hand (vs.
rc.shutdown) and it still doesn't matter.
Any other suggestions?
Also, as I said I haven't lost any data thus far and other than seeing
that message it works just fine. Am I 1) just "lucky" so far (and will
eventually not be so lucky), 2) is it just cleaning up after itself on
reboot (my rc.securelevel script runs an fsck -p on the volume before
mounting it), or 3) is it actually working but just not very pretty?
Would stackable softraid volumes work in near future or is it big
problem as how softraid was designed?
Generally speaking they already "work" - there are just some caveats,
primarily relating to assembly and shutdown. Most of the issues are fairly
easily fixed or are at least solvable (the shutdown ordering should be
simple - I just need to move it up the priority list). That said, longer term
I would rather have disciplines such as RAID1C and RAID10 that handle the
stacking internally and allow for better operation and management.
With that approach (RAID1C) would that also work when the entire volume
isn't encrypted, like in my case where only one partition of the HDD is
crypto?
Either way, it sounds fantastic and having "smooth" RAID (esp. crypto)
operations, l think, would be a huge feather in OpenBSD's cap. I
haven't tried full disk encryption yet, maybe on a test box one day,
because I just don't need that overhead for every disk access.
--
Scott McEachern
https://www.blackstaff.ca
