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"

From Obsolete Lustre Wiki
Jump to navigationJump to search
m (Protected "Architecture - Open by fid" ([edit=sysop] (indefinite) [move=sysop] (indefinite)))
 
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.

Purpose

Open by fid returns a file descriptor based on a FID. This is quite similar to the controversial open by inode calls found elsewhere.

Implementation Choices

There several considerations for implementation:

  1. use an ioctl on the root directory of the lustre file system - advantage: simple implementation
  2. 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
  3. an easy to use, in kernel API is also required

Decomposition of the design

The architecture of open by fid decomposes into several pieces:

  1. a local mechanism to generate a file descriptor from a ficticious pathname in /proc and/or through an ioctl
  2. the rpc mechanisms with the MDS to get that file descriptor (based on existing re-open by fid code, used during recovery)
  3. a mechanism to set flags and default flags on fid file descriptors
  4. verification and implementation of the recovery of the file descriptor during an MDS failure
  5. verification and implementation of correct behavior when file descriptor calls are made
    1. IO using the file descriptor: this can be dependent on flags, e.g. IO may or may not trigger cache miss handling
    2. fstat, fchown, ftruncate etc.


Use cases to cover

Description Semantics
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