Hi !
I came across another vblade variant some time ago (derived from the coraid one) which seems to point into that direction:
http://evblade.kwaak.net/
unfortunately i didn`t yet have the time to take a closer look and just from the description i didn`t understand the very details about this "fork".
iirc, this fork has been done by Ard van Breemen <ard@...>
greetings
roland
support@... schrieb am 01.02.06 20:29:49:
>
> On Tue, Jan 31, 2006 at 04:06:00PM -0800, Don Hiatt wrote:
> > Hi Ed,
> >
> > I was wondering if you have given any thought to adding a locking
> > mechanism to vblade?
>
> Yes, the designers of the ATA over Ethernet protocol included the
> config string feature in order to supply a nice mechanism for
> locking.
>
> Locking is cooperative, because it is entirely possible to use a
> single AoE device from multiple hosts safely by cooperating.
> Clustering software can do it, and hosts that use different areas of
> the disk (e.g., separate partitions) can do it too.
>
> > By locking I mean the ability to allow only a
> > single client to have exclusive access to an AoE mounted drive. For
> > example:
> > * Say we have a server (S1) with a drive it wants to export (/dev/sda)
> > * On the same network we have multiple clients (C1,C2,C3,...,Cn)
> > * When S1 starts up all clients will be aware that a drive is available for
> > mounting.
> > * Say C1 mounts the device but then C2,C3 try to mount the drive on S1. A
> > locking mechanism would prevent Cn from doing so (I'd actually serialize all requests
> > to avoid race conditions).
>
> If they are using GFS, then they can all mount the same filesystem
> safely, so blocking access to everyone but the first host would be
> incorrect. The vblade can't anticipate how remote hosts are going to
> use it.
>
> > What do you think? I was thinking of adding a mechanism to provide this
> > sort of locking/reservation system like so (sorry for the primitive artwork) :)
>
> Well, RocketDivision has created a Windows driver that makes use of
> the config string feature in the AoE protocol. In fact, early
> versions of the vblade didn't support the feature, but now you can use
> it for locking.
>
> This is the document specifying the AoE protocol itself:
>
> http://www.coraid.com/documents/AoEr8.txt
>
> Here's an example of a way to use the config string feature for
> cooperative locking if the hosts are not willing or able to share the
> vblade safely, and you don't want to configure each host to use only
> the AoE devices you've allocated for it.
>
> In the example, the convention is that the "owner" of the AoE device
> has its MAC address in the AoE device's config string. Each host
> wanting to use an AoE device uses a Query Config command with the set
> config string subcommand, using its MAC address as the config string.
>
> The AoE device will only set the config string to the querying host's
> MAC address if its config string is currently empty. That means the
> first host to do the query config setting the config string gets
> ownership of the AoE device. All the other hosts will get an error
> response.
>
> To release the AoE device, the owner force sets the config string to
> an empty config string.
>
> > S1 C1 C2 C3 ... Cn
> > [Announce]------->*
> > \----------->*
> > \----------------------->*
> > \----------------------------------------->*
> >
> > *<----------------[C1 bind request]
> > *<----------------------------[C2 bind request]
> >
> > [ACK bind]------->* // C1 now has exclusive use of S1's drive (/dev/sda)
> > [NACK bind]------------------->* // C2..Cn rejected
> >
> > // time passes...
> >
> > *<----------------[C1 teardown bind request] // explicit teardown by C1
> > [Announce]------> Repeat as above
> >
> > // An implicit teardown will also be supported if a client fails to respond to a ping
> >
> > [PING]----------->*
> > \----------->*
> > \----------------------->*
> > \----------------------------------------->*
> > [TIMEOUT, C1 does not respond to PING]
> > //Tear down link and repeat announce
> >
> > // C1 will also drop the bind with S1 if the link fails for whatever reason.
> > // I would also have a "force tear down" to allow a "forced takeover" of a device for testing. :)
> >
> >
> > Your comments would be greatly appreciated. Would you consider folding in the above ability
> > if I were to implement it, or some version of it?
>
> The vblade has to conform to the AoE spec, and the spec is
> deliberately open ended, allowing the users of the device to
> coordinate as they like, sharing the device or using it exclusively
> via the config string. The mechanism is light enough to be supported
> by inexpensive hardware.
>
> I guess, though, since it's open source, you could always change the
> vblade as you like for your own purposes, so that it enforces a
> specific policy instead of providing a general mechanism.
>
> --
> Ed L Cashin <ecashin@...>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Aoetools-discuss mailing list
> Aoetools-discuss@...
> https://lists.sourceforge.net/lists/listinfo/aoetools-discuss
__________________________________________________________________________
Erweitern Sie FreeMail zu einem noch leistungsstarkeren E-Mail-Postfach!
Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131

On Tue, Jan 31, 2006 at 04:06:00PM -0800, Don Hiatt wrote:
> Hi Ed,
>
> I was wondering if you have given any thought to adding a locking
> mechanism to vblade?
Yes, the designers of the ATA over Ethernet protocol included the
config string feature in order to supply a nice mechanism for
locking.
Locking is cooperative, because it is entirely possible to use a
single AoE device from multiple hosts safely by cooperating.
Clustering software can do it, and hosts that use different areas of
the disk (e.g., separate partitions) can do it too.
> By locking I mean the ability to allow only a
> single client to have exclusive access to an AoE mounted drive. For
> example:
> * Say we have a server (S1) with a drive it wants to export (/dev/sda)
> * On the same network we have multiple clients (C1,C2,C3,...,Cn)
> * When S1 starts up all clients will be aware that a drive is available for
> mounting.
> * Say C1 mounts the device but then C2,C3 try to mount the drive on S1. A
> locking mechanism would prevent Cn from doing so (I'd actually serialize all requests
> to avoid race conditions).
If they are using GFS, then they can all mount the same filesystem
safely, so blocking access to everyone but the first host would be
incorrect. The vblade can't anticipate how remote hosts are going to
use it.
> What do you think? I was thinking of adding a mechanism to provide this
> sort of locking/reservation system like so (sorry for the primitive artwork) :)
Well, RocketDivision has created a Windows driver that makes use of
the config string feature in the AoE protocol. In fact, early
versions of the vblade didn't support the feature, but now you can use
it for locking.
This is the document specifying the AoE protocol itself:
http://www.coraid.com/documents/AoEr8.txt
Here's an example of a way to use the config string feature for
cooperative locking if the hosts are not willing or able to share the
vblade safely, and you don't want to configure each host to use only
the AoE devices you've allocated for it.
In the example, the convention is that the "owner" of the AoE device
has its MAC address in the AoE device's config string. Each host
wanting to use an AoE device uses a Query Config command with the set
config string subcommand, using its MAC address as the config string.
The AoE device will only set the config string to the querying host's
MAC address if its config string is currently empty. That means the
first host to do the query config setting the config string gets
ownership of the AoE device. All the other hosts will get an error
response.
To release the AoE device, the owner force sets the config string to
an empty config string.
> S1 C1 C2 C3 ... Cn
> [Announce]------->*
> \----------->*
> \----------------------->*
> \----------------------------------------->*
>
> *<----------------[C1 bind request]
> *<----------------------------[C2 bind request]
>
> [ACK bind]------->* // C1 now has exclusive use of S1's drive (/dev/sda)
> [NACK bind]------------------->* // C2..Cn rejected
>
> // time passes...
>
> *<----------------[C1 teardown bind request] // explicit teardown by C1
> [Announce]------> Repeat as above
>
> // An implicit teardown will also be supported if a client fails to respond to a ping
>
> [PING]----------->*
> \----------->*
> \----------------------->*
> \----------------------------------------->*
> [TIMEOUT, C1 does not respond to PING]
> //Tear down link and repeat announce
>
> // C1 will also drop the bind with S1 if the link fails for whatever reason.
> // I would also have a "force tear down" to allow a "forced takeover" of a device for testing. :)
>
>
> Your comments would be greatly appreciated. Would you consider folding in the above ability
> if I were to implement it, or some version of it?
The vblade has to conform to the AoE spec, and the spec is
deliberately open ended, allowing the users of the device to
coordinate as they like, sharing the device or using it exclusively
via the config string. The mechanism is light enough to be supported
by inexpensive hardware.
I guess, though, since it's open source, you could always change the
vblade as you like for your own purposes, so that it enforces a
specific policy instead of providing a general mechanism.
--
Ed L Cashin <ecashin@...>

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details