Where I think I'm going it to store the Handle of the "owner" of each
object as an attribute in the object. For dfiles, this would be the
handle of the metafile, for metafiles this would be the handle of the
directory (works for now since we don't do hard links). Then We'll send
reference the owner handle when we create the capability. This would be
translated into a server name, and we tie the key pairs to the servers.
Thus, if we change which server handles a data space, the owner object
handle will translate to the new server, and it will use that server's
keys. The allocating and management of keys will be tied to the
servers. this should even allow migration of objects between data
spaces. If data is migrated to new servers, probably the new servers
will each get new keys. We plan to have a mechanism to flush and
rebuild key databases for this eventuality (basically we can request
public keys from a server with a PVFS request - they keys are sent in a
cert signed by CA). Finally, having this information added might be uf
use to the fsck program, as it would allow stray dfiles to be mapped
back to the owning metafile, etc. The only problem would come if we
actually change the handle of a file, which would require updating all
of the dfiles - but we don't do that very often.
Thoughts?
Walt
Sam Lang wrote:
Walt,
I think for your purposes you should probably just have each server/fs
generate a uuid. Keep in mind that everything (including the endpoint
string and handle ranges) can change in the config file without
recreating the storage spaces. This often happens when admins want to
migrate to other servers.
It might help to think about the storage space (and each fs within them)
as the thing you want to reference with a permanent globally unique-id.
Our servers just manage those storage spaces, and the endpoint strings
just provide an address (which can change over time).
If you were to use a uuid for each server/fs, you probably want random
instead of time/host-based, so that you can move servers around without
making the id invalid. If you wanted them in the config file, they
could be part of the Alias mapping, and genconfig could just generate
them with uuidgen or something. We've talked about having something
like this for zero-conf, although that was more transient on a
per-server start basis, to provide a consistent view if the config
changed -- so a different purpose.
Alternatively, if that's all too over the top, and you just want an
integer instead of a string, the index into the server list is no worse
than the endpoint string.
-sam
On May 15, 2008, at 1:23 PM, Rob Ross wrote:
Yes, having multiple file systems would really mess with you because
you could have the same handle for more than one FS. You sure you
don't want to just use a string name?
Rob
On May 15, 2008, at 1:10 PM, Nicholas Mills wrote:
Thanks for your help everyone.
David and I have decided to use the first handle in the server's
mapping to identify the server. We are at the point now where we need
to find a handle range given a host alias. Does anyone know of a
quick and easy way to do this?
There is also the question of which handle range to use. Do we use
the meta handles or the data handles? Also, will having multiple
filesystems complicate anything?
--Nick
On Tue, May 13, 2008 at 4:10 PM, Phil Carns <[EMAIL PROTECTED]> wrote:
I don't think we have any globally valid fixed sized identifier for
the servers. The only option I know if would be to use a handle (for
example, the first handle in the server's mapping) to represent each
server. I think just using the string name would be safer, though.
-Phil
Walter Ligon wrote:
Hey guys,
we're needing to send a server host identification on the wire. In
the config the host_id appears to be a variable length string.
Should we just use that, or is there something else of fixed size I'm
not aware of?
Walt
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
