forked from torvalds/linux
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
NFSv4.1: pnfs: full mount/umount infrastructure
Allow a module implementing a layout type to register, and have its mount/umount routines called for filesystems that the server declares support it. Signed-off-by: Fred Isaman <[email protected]> Signed-off-by: Marc Eshel <[email protected]> Signed-off-by: Andy Adamson<[email protected]> Signed-off-by: Bian Naimeng <[email protected]> Signed-off-by: Benny Halevy <[email protected]> Signed-off-by: Trond Myklebust <[email protected]>
- Loading branch information
Fred Isaman
authored and
Trond Myklebust
committed
Oct 24, 2010
1 parent
85e174b
commit 02c35fc
Showing
5 changed files
with
151 additions
and
4 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,48 @@ | ||
Reference counting in pnfs: | ||
========================== | ||
|
||
The are several inter-related caches. We have layouts which can | ||
reference multiple devices, each of which can reference multiple data servers. | ||
Each data server can be referenced by multiple devices. Each device | ||
can be referenced by multiple layouts. To keep all of this straight, | ||
we need to reference count. | ||
|
||
|
||
struct pnfs_layout_hdr | ||
---------------------- | ||
The on-the-wire command LAYOUTGET corresponds to struct | ||
pnfs_layout_segment, usually referred to by the variable name lseg. | ||
Each nfs_inode may hold a pointer to a cache of of these layout | ||
segments in nfsi->layout, of type struct pnfs_layout_hdr. | ||
|
||
We reference the header for the inode pointing to it, across each | ||
outstanding RPC call that references it (LAYOUTGET, LAYOUTRETURN, | ||
LAYOUTCOMMIT), and for each lseg held within. | ||
|
||
Each header is also (when non-empty) put on a list associated with | ||
struct nfs_client (cl_layouts). Being put on this list does not bump | ||
the reference count, as the layout is kept around by the lseg that | ||
keeps it in the list. | ||
|
||
deviceid_cache | ||
-------------- | ||
lsegs reference device ids, which are resolved per nfs_client and | ||
layout driver type. The device ids are held in a RCU cache (struct | ||
nfs4_deviceid_cache). The cache itself is referenced across each | ||
mount. The entries (struct nfs4_deviceid) themselves are held across | ||
the lifetime of each lseg referencing them. | ||
|
||
RCU is used because the deviceid is basically a write once, read many | ||
data structure. The hlist size of 32 buckets needs better | ||
justification, but seems reasonable given that we can have multiple | ||
deviceid's per filesystem, and multiple filesystems per nfs_client. | ||
|
||
The hash code is copied from the nfsd code base. A discussion of | ||
hashing and variations of this algorithm can be found at: | ||
http://groups.google.com/group/comp.lang.c/browse_thread/thread/9522965e2b8d3809 | ||
|
||
data server cache | ||
----------------- | ||
file driver devices refer to data servers, which are kept in a module | ||
level cache. Its reference is held over the lifetime of the deviceid | ||
pointing to it. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters