WARNING: This is the _old_ Lustre wiki, and it is in the process of being retired. The information found here is all likely to be out of date. Please search the new wiki for more up to date information.
Difference between revisions of "Architecture - Open by fid"
|(One intermediate revision by the same user not shown)|
|Line 1:||Line 1:|
'''''Note:''''' The content on this page reflects the state of design of a Lustre feature at a particular point in time and may contain outdated information.
'''''Note:''' ''The content on this page reflects the state of design of a Lustre feature at a particular point in time and may contain outdated information.
== Purpose ==
== Purpose ==
Latest revision as of 14:19, 22 January 2010
Note: The content on this page reflects the state of design of a Lustre feature at a particular point in time and may contain outdated information.
Open by fid returns a file descriptor based on a FID. This is quite similar to the controversial open by inode calls found elsewhere.
There several considerations for implementation:
- use an ioctl on the root directory of the lustre file system - advantage: simple implementation
- open the file /proc/fs/lustre/.../open_by_fid/FID - major advantage: this is a standard open call, so it can be used by unmodified utilities
- an easy to use, in kernel API is also required
Decomposition of the design
The architecture of open by fid decomposes into several pieces:
- a local mechanism to generate a file descriptor from a ficticious pathname in /proc and/or through an ioctl
- the rpc mechanisms with the MDS to get that file descriptor (based on existing re-open by fid code, used during recovery)
- a mechanism to set flags and default flags on fid file descriptors
- verification and implementation of the recovery of the file descriptor during an MDS failure
- verification and implementation of correct behavior when file descriptor calls are made
- IO using the file descriptor: this can be dependent on flags, e.g. IO may or may not trigger cache miss handling
- fstat, fchown, ftruncate etc.
Use cases to cover
|deployment||open by fid is done on Lustre client nodes|
|open a fid residing the mds||file handle for file io|
|open a fid residing on oss||file handle for object io|
|open /proc/fs/lustre/something/FID||returns synthetic file descriptor for the object|
|open /proc/fs/lustre/something/FID_FLAGS||returns synthetic file descriptor for the object and sets flags on the file descriptor, for example to avoid cache misses|
|open_by_fid()||ioctl with the same functionality as opening the /proc file.|
|authorization||servers allow open_by_fid() only from certain nodes|
|mount options||clients do not enable open by fid unless a mount option is passed, clients can set the default flags to be used when open by fid file descriptors are generated.|
|Failure modes||the open calls should be subject to replay / resend, including the restoration of flags on the server|