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