On Thu, 23 Jun 2011, Alexander Motin wrote: > On 23.06.2011 20:53, Gavin Atkinson wrote: > > While debugging a problem that looks like it was unrelated to geom_raid, > > I realised that it tastes all providers, including each partition and > > slice on raid devices it itself created. > > > > Given that geom_raid is purely a replacement for ataraid, the only place > > that the metadata can be valid is on the raw disk itself. > > In general case nothing prevents from using graid on partitions (instead of > gmirror/gstripe/...) if BIOS support is not needed. I think this check at > least should be moved to specific metadata modules in case if we later add > support for abstract gxxx metadata formats.
OK, thanks. I had believed that this was purely for use on hardware. If the intention is that this module can be used on arbitrary providers, then I see no reason to change things. > > Also, should geom_raid be in GENERIC? ataraid was, and it's one less > > "gotcha" for upgrades. Given the lack of ar0 -> raid/r0 aliases, the > > upgrade is painful enough for users already, putting it in GENERIC may > > at least help slightly... > > Aggressive tasting for each metadata format was actually the reason why I > haven't added it. If we load all GEOM modules, then some floppy tasting will > take ages. OK, that makes sense. I had a bit of a look this evening as to the best way to try to get code in place to provide /dev/arX compatibility nodes whenever a geom_raid array is discovered. Is there any reason that I shouldn't take exactly the same approach as you have done with the adX -> adaX compatibility shims? Thanks, Gavin _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-geom To unsubscribe, send any mail to "[email protected]"
