On Sat, 9 Feb 2013, Scott McEachern wrote:
> 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
umount via DUID does not work currently - this will be fixed shortly after the
next release freeze has ended.
> 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?
Mostly (3) - if you are unmounting the file system then the actual chance of
data loss is low (file systems should unmount on shutdown before the softraid
volumes are torn down). On shutdown of a volume the metadata is updated and
this is what is failing.
> >> 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?
Since softraid works with partitions and not disks, you could turn sd0a/sd1a
into a RAID1C volume and sd0d/sd1d into a pure RAID1 volume (rather than
splitting up the RAID1 volume). The only real downside to this is that a
physical disk failure then requires two separate rebuilds.
> 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.
--
"Reason is not automatic. Those who deny it cannot be conquered by it.
Do not count on them. Leave them alone." -- Ayn Rand
