I don't understand this. Is there a scheme whereby there is no mapping of the handle ID to a server? If not, then what we are talking about, I think, is whether the server mapping is fixed or not. The idea behind the current scheme was to make the mapping of servers to handles flexible. That said, the specific implementation might could be better. For example, using 128 bits we could have a 64 bit segment tag and a 64 bit handle ID. The segment tag would map the handle to a server via the tables, and the ID would be unique within that segment. This might simplify some things without losing the flexibility we have.

As it is, the server can still randomly pick an ID, or a client could randomly pick an ID, they just have to do it within a range, which isn't particularly hard. With this suggested modification we could "eliminate" the range by giving all "handle ranges" a built-in extent of 64 bits, which I think is the same as what you were suggesting.

If I'm not being clear, let me know and I'll try again. Or, if I don't understand the problem, let me know that.

Walt

Pete Wyckoff wrote:

For create scalability, you may want the client to pick handle IDs
and offer those to the server, so that you can optimistically create
a metafile assuming there are no collisions on the server.  These
guessed handle IDs can be random though.  We did not implement this
as it would be quite expensive if implemented in terms of the
existing extent/extentlist/ledger data structures.

In the OSD work, we have to do painful things to return a handle ID
in a particular range.  I would much rather have the server pick a
random ID and give it to the client.  Or for the client to try to
pick a particular ID and hope there is no collision at the server.

So I'd like to discard the idea of pre-assigned per-server handle
ranges and augment our notion of PVFS_handle to include some sort of
"server identifier" as well as the 64-bit ID that is private to the
particular device on which the object sits.

Various distributed FS implementations for wide-area use seem to be
happy with 128-bit handles and assume collisions will never happen.
This always struck me as wildly reckless, but maybe it is time to
accept the fact that these number spaces are really big.

                -- Pete
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers

--
Dr. Walter B. Ligon III
Associate Professor
ECE Department
Clemson University
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers

Reply via email to