Data Server File Handle

Data Server File Handle Makeup and Rationale

The goals

• Construct filehandles for the MDS as they are today to minimize impact to existing code base
• Data server filehandles must not include the traditional export-fid information to allow for reshare of a filetree using a different shared directory (given the impact on the filehandle content)
• Delay object creation and hence filehandle generation at the data-servers to allow for reasonable scalability on file creation
• Allow for multiple pools to be hosted by a single data-server (this allows for easy addition of new pools or pools with different characteristics or consolidation of pools from N data-servers to 1)
• Need an easy way to associate file object at data-server with the MDS' file system such that invalidate of cached state can be done efficiently (e.g. a reshare with different security mechanisms)
• Attempt to lessen the need for layoutrecall as a result in data-server filehandle change

The data server file handle is made up of the following parts:

What you will find in each part of the file handle

MDS ID - A Solaris Data Server can store the data for multiple different metadata servers. The purpose of the MDS ID is to tell the data server to which metadata server to send its state and auth checking messages (i.e. DS_CHECKSTATE) to. The metadata server must place the same value in the MDS ID of the file handle as it returned to the Data Server in DS_EXIBI. This means that the MDS ID portion of the file handle may change.

MDS Storage ID (MDS SID) - The MDS Storage ID is an abstraction for a piece of storage on the data server (identified by a ds_guid which is made up of the zpool guid and dataset guid). The purpose of the MDS SID is to allow for objects to move from one zpool to another zpool on the metadata server and the data server (e.g. zfs send/recv). Additionally, if the dataset is replicated to another data server it may end up (depending on the type of replication) with a different ds_guid and the MDS would need to walk the filetree updating the layouts with the new location. With the MDS level of abstraction, this does not need to be done. This requires the metadata server to have a table of the data server ds_guids and a generated id for each of those. This generated id will be the value that is encoded in the data server file handle. Since this is encoded in the file handle, the data about the mapping from the generated id to the ds_guid will need to be stored persistently on the MDS.

As an example, if the Data Server has 2 storage the Metadata Server will have to keep track of the following:

Then in the case that the objects in the zpool associated with Generated ID "1" move to a new zpool (lets say "def"), then the table will get updated to look like this:

Further details coming...