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