geom_raid tasting providers that can't be raw disks

Gavin Atkinson gavin at FreeBSD.org
Thu Jun 23 23:11:48 UTC 2011


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


More information about the freebsd-geom mailing list