kclient: fix up patchset comments, docs

diff --git a/src/kernel/ceph.txt b/src/kernel/ceph.txt
index 09b325c1bbaf52d127a4133a284e005e81ac9793..26b014e1949cbc165f140403aae40defd55c947e 100644 (file)
--- a/src/kernel/ceph.txt
+++ b/src/kernel/ceph.txt
@@ -78,8 +78,8 @@ off if the monitor is using the default.  So if the monitor is at
 
  # mount -t ceph 1.2.3.4:/ /mnt/ceph
 
-is sufficient.  If mount.ceph is installed, a hostname can be used
-instead of an IP address.
+is sufficient.  If /sbin/mount.ceph is installed, a hostname can be
+used instead of an IP address.
 
 
 
@@ -120,8 +120,14 @@ Mount Options
        must rely on TCP's error correction to detect data corruption
        in the data payload.
 
+  noasyncreaddir
+       Disable client's use its local cache to satisfy readdir
+       requests.  (This does not change correctness; the client uses
+       cached metadata only when a lease or capability ensures it is
+       valid.)
 
-Debugging options:
+
+Debugging options (these are also changeable via debugfs):
 
   debug=N
        Specify the level of debug output for the Ceph client.  Larger

diff --git a/src/kernel/import_patch_set_into_linux_git.sh b/src/kernel/import_patch_set_into_linux_git.sh
index 52bcedb30573a201ed2c709bbfa2fa2df752e0c8..74fd6f792a17de55745a94f5ea5b38d6570e5b47 100755 (executable)
--- a/src/kernel/import_patch_set_into_linux_git.sh
+++ b/src/kernel/import_patch_set_into_linux_git.sh
@@ -81,14 +81,8 @@ Inode cache and inode operations.  We also include routines to
 incorporate metadata structures returned by the MDS into the client
 cache, and some helpers to deal with file capabilities and metadata
 leases.  The bulk of that work is done by fill_inode() and
-fill_trace().
-
-Most MDS responses include a "trace" of dentry and inode information
-from the inode in question back to the root.  fill_trace() takes pains
-to ensure that the dcache is updated safely.  If the directory i_mutex
-is not already held and cannot be taken (via trylock), that segment of
-the trace is skipped.  If an inode is linked incorrectly, we attempt
-to reattach it in the correct position in the hierarchy.
+fill_trace(), which incorporate metadata included into the reply
+into the client's cache.
 
 EOF
 
@@ -153,14 +147,16 @@ used to control the ordering of messages within each session.
 
 An MDS request may generate two responses.  The first indicates the
 operation was a success and returns any result.  A second reply is
-sent when the operation commits to the journal.  Note that locking
-on the MDS ensures that the results of updates are visible only to
-the updating client until the operation commits.
+sent when the operation commits to disk.  Note that locking on the MDS
+ensures that the results of updates are visible only to the updating
+client before the operation commits.
 
 Requests are linked to the containing directory so that an fsync will
 wait for them to commit.
 
-If an MDS fails and/or recovers, we resubmit requests as needed.
+If an MDS fails and/or recovers, we resubmit requests as needed.  We
+also reconnect existing capabilities to a recovering MDS to
+reestablish that shared session state.
 
 EOF
 
@@ -214,7 +210,7 @@ ceph: monitor client
 The monitor cluster is responsible for managing cluster membership
 and state.  The monitor client handles what minimal interaction
 the Ceph client has with it: checking for updated versions of the
-MDS and OSD maps, and getting statfs() information.
+MDS and OSD maps, getting statfs() information, and unmounting.
 
 EOF
 
@@ -229,16 +225,16 @@ which operations are allowed.
 
 In the case of an EXCL (exclusive) or WR capabilities, the client is
 allowed to change inode attributes (e.g., file size, mtime), noting
-it's dirty state in the ceph_cap, and asynchronously flush that
+its dirty state in the ceph_cap, and asynchronously flush that
 metadata change to the MDS.
 
 In the event of a conflicting operation (perhaps by another client),
 the MDS will revoke the conflicting client capabilities.
 
-A subset of capabilities (termed 'rdcaps') are opportunistically
-issued by the MDS to grant the a client read lease on metadata, and
-time out automatically.  Other capabilities (write capabilities, and
-those that are "wanted" due to an open file) are explicitly released.
+In order for a client to cache an inode, it must hold a capability
+with at least one MDS server.  When inodes are released, release
+notifications are batched and periodically sent en masse to the MDS
+cluster to release server state.
 
 EOF
 
@@ -255,7 +251,7 @@ make this work.
 
 Portions of the hierarchy that belong to the same set of snapshots
 are described by a single 'snap realm.'  A 'snap context' describes
-the set of snapshots that exist for a given piece of metadata.
+the set of snapshots that exist for a given file or directory.
 
 EOF
 
@@ -309,7 +305,7 @@ ceph: debugfs
 
 Basic state information is available via /debug/ceph, including
 instances of the client, fsids, current monitor, mds and osd maps,
-and hooks to adjust debug levels.
+outstanding server requests, and hooks to adjust debug levels.
 
 EOF