Re: patch for raidframe and non 512 byte sector devices

[buhrow%lothlorien.nfbcal.org@localhost (Brian Buhrow)]

        hello.  Thanks for this patch.  I've been thinking about some other
patches for raidframe, and thought I'd share my thoughts with the list.
These patches reminded me  that I wanted to write down these thoughts, and
since you're in the code already, Matt, I thought you might have some
immediate ideas for some of them.

1. Raidframe autoconfigure on raw disks.
        From what I can tell, raidframe can't autoconfigure on a disk unless
the disk has either a BSD disklabel, or a gpt wedge and the raidframe lives
inside the defined wedge or in a BSD partition.  However, it is possible to
configure raidframe on a raw disk without such a disklabel or gpt table.
My thought was to teach raidframe a third way of autoconfiguring its
components.  Namely, using the same trick the boot blocks use to boot off
of raid1 partitions.  That is, if there is no disklabel containing a raid
partition, or no wedge containing one, seek to the offset where the raid
label would go on a raw disk and see if it exists.
If enough labels containing the right data exist, and the raid is set to
autoconfigure, then configure a raid set.
        Is there a reason this hasn't been done already?  Are there compelling
reasons not to do this that I haven't thought of?  It seems like a simple
change, but I haven't actually done more than glance at the code as yet, so
I can't  be  sure it's as trivial as it sounds.

2.  Lazy calculation of parity.
        One of the down sides of raidframe at this moment is the time it takes
to perform the initial parity on a large raid set.  The recent patches to
fix the parity quickly after a crash are great, but I don't believe they solve 
the initial calculation problem.  If I'm wrong, then please let me know, and
I'll be quiet.  If not, then I'm wondering if there is a way to have the
parity slices be in one of three states:

A.  Clean - Parity is known and good.

B.  Dirty - parity is known to be unclean and needs to be rechecked.

C.  Unused - This slice has never been written to and so can be fixed when
the initial write request to it is done.

        It might be that writing what ever data in the parity bit maps is
required to note that third state is just as expensive in terms of time as
writing the parity itself, I don't actually know, but if not, then it might
be a way of configuring and using large raid sets quickly without having to
wait for that first parity check.

Just some thoughts.
-thanks
-Brian