In message <[EMAIL PROTECTED]>, Rasmus Skaarup writes:
>> Basically when a new "g_provider" is created it is offered to each method
>> in turn and if that method likes it, it can stick g_geom on top of it.
>
>Ahh.. But do you rule out the possibility that two methods could apply to
>a g_provider? Or is this even a problem?
the relationships in geom are:
g_method --- 1 : N --- g_geom
Each method can have multiple instances.
g_geom --- 1 : N --- g_consumer
An instance can attach to multiple providers
(striping, mirroring, raid5)
g_geom --- 1 : N --- g_provider
An instance can split into more providers.
(BSD/disklabel, MBR)
g_provider --- 1 : N --- g_consumer
Multiple consumers can attach to one provider.
>> How you would recognize the same disk on thre different paths is a good
>> question. We could implement (if we don't already have it) an
>> ioctl/BIO_GETATTR which returns the serial number(s) of the diskdevice
>> and you could query that.
>
>Hmm, but I'm not sure all kinds of storage devices have serialnumbers that
>could be fetched (tape devices for instance?) and can we rely on the
>hardware manufacturers to provide unique serialnumbers?
Well, the recognition/configuration issue is not one GEOM magically can
solve for you, but GEOM promises that if you can recognize it and
configure it, GEOM will not get in your way for doing what you want.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
