From: Andrew C. Uselton Date: Thu, 30 Jul 2015 17:27:17 +0000 (-0500) Subject: LUDOC 299 protocol: Spell-check document X-Git-Url: https://git.whamcloud.com/?p=doc%2Fprotocol.git;a=commitdiff_plain;h=1c8320fcc3906ae5de4e0f58bbba96e0d91a9bf4 LUDOC 299 protocol: Spell-check document [2015-07-29] Go through all of the text and runa spell-checker on it. Signed-off-by: Andrew C. Uselton Change-Id: I4a38d6cd0b359fa3528280fc032eef1de890c3d5 Reviewed-on: http://review.whamcloud.com/15809 Tested-by: Jenkins --- diff --git a/client.txt b/client.txt index adab69e..d108756 100644 --- a/client.txt +++ b/client.txt @@ -2,6 +2,6 @@ Client ~~~~~~ Host systems that mount the Lustre file system and are generally -refered to as "clients" of the file system services. Most, but not +referred to as "clients" of the file system services. Most, but not all, Lustre protocol actions (remote procedure calls, or RPCs) are initiated by clients. diff --git a/getattr.txt b/getattr.txt index 44edcbf..65c40b9 100644 --- a/getattr.txt +++ b/getattr.txt @@ -159,7 +159,7 @@ with this set of valid fields (0x8080022f8f): | OBD_MD_FLACL | ACL |==== -As a bonus the MDT returnes layout information about the file, so that +As a bonus the MDT returns layout information about the file, so that Client1 can get attribute information from the OST(s) responsible for the file's objects (if any). @@ -185,7 +185,7 @@ The ldlm-enqueue-request.png diagram resembles this text art: See <>. -*4 - The OST invokes a glimps lock callback on Client2.* +*4 - The OST invokes a glimpse lock callback on Client2.* Client2 previously had a lock on the desired resource, and the glimpse induces Client2 to flush its buffers, if needed, and update the OST @@ -209,7 +209,7 @@ See <>. *5 - Client2 replies with LVB data for the OST.* The OST is waiting to hear back from Client2 to update size and time -attributes, if needed, due to Client2 chache being flushed to the +attributes, if needed, due to Client2 cache being flushed to the OST. The glimpse allows the information to return to the OST, and thereby get passed to Client1, without taking the lock from Client2. @@ -225,7 +225,7 @@ The ldlm-gl-callback-reply.png diagram resembles this text art: ------------------------- ////////////////////////////////////////////////////////////////////// -The 'ost_lvb' data from Client2 has atribute data to update the OST. +The 'ost_lvb' data from Client2 has attribute data to update the OST. *6 - The OST replies with the updated attribute information.* diff --git a/getxattr.txt b/getxattr.txt index 8cb5e49..8bff149 100644 --- a/getxattr.txt +++ b/getxattr.txt @@ -57,7 +57,7 @@ text art: ------------------------------------------------------- ////////////////////////////////////////////////////////////////////// -See <>. +See <>. *2 - The MDT replies with an LDLM_ENQUEUE with the extended attributes data.* diff --git a/glossary.txt b/glossary.txt index 37ad9f2..fb1d274 100644 --- a/glossary.txt +++ b/glossary.txt @@ -7,7 +7,7 @@ and the protocols used to implement them. [glossary] Object Storage Device (OSD):: The OSD is the storage on a server that holds objects or metadata. The -two kinds of file system available ofr OSDs are ldiskfs and ZFS. +two kinds of file system available for OSDs are ldiskfs and ZFS. Client:: A Lustre client is a computer taking advantage of the services @@ -43,7 +43,7 @@ different for each file. The amount of space reserved for layout information is a small as possible given the maximum stripe count on the file system. Clients, servers, and the distributed lock manager will all need to be aware of this size, which is communicated in the -'ocd_max_easize' fieled of the <> structure. +'ocd_max_easize' field of the <> structure. LNet:: A lower level protocol employed by PtlRPC to abstract the mechanisms diff --git a/introduction.txt b/introduction.txt index f4fcc65..a6cc40e 100644 --- a/introduction.txt +++ b/introduction.txt @@ -19,7 +19,7 @@ interface, originally based on Sandia Portals <>, to Lustre clients and servers. Lustre, in turn, layers its own protocol atop LNet. This document describes the Lustre protocol. -The remainder of the introduciton presents several concepts that +The remainder of the introduction presents several concepts that illuminate the operation of the Lustre protocol. In <> a subsection is devoted to each of several semantic operations (setattr, statfs, ...). That discussion introduces diff --git a/ldlm_cancel.txt b/ldlm_cancel.txt index 6830bb7..97d28b2 100644 --- a/ldlm_cancel.txt +++ b/ldlm_cancel.txt @@ -22,7 +22,7 @@ RPC descriptor. <> 'ldlm_request':: The request RPC identifies the lock being canceled. Only the first -'lock_handle' field is used. The rest of the 'ldlm_request' sturcture +'lock_handle' field is used. The rest of the 'ldlm_request' structure is not used. <> .LDLM_CANCEL Reply Packet Structure diff --git a/ldlm_enqueue.txt b/ldlm_enqueue.txt index 1392f4a..f1eaa20 100644 --- a/ldlm_enqueue.txt +++ b/ldlm_enqueue.txt @@ -256,14 +256,14 @@ Access Control List data associated with a resource. 'EA data':: The names of any extended attributes associated with the resource. The -names are null-terminated strings concatenated into a single sequnce. +names are null-terminated strings concatenated into a single sequence. 'EA vals':: A block of data concatenating the values for the extended attributes listed in "EA vals". 'EA lens':: -The sizes of the extended attirbute values. This is a sequence of +The sizes of the extended attribute values. This is a sequence of 32-bit unsigned integers, one for each extended attribute. The sizes give the length of the corresponding extended attribute in the "EA vals" block of data. Thus the sum of those sizes diff --git a/ldlm_gl_callback.txt b/ldlm_gl_callback.txt index c0ea49e..b8594eb 100644 --- a/ldlm_gl_callback.txt +++ b/ldlm_gl_callback.txt @@ -9,7 +9,7 @@ it. image::ldlm-gl-callback-request.png["LDLM_GL_CALLBACK Request Packet Structure",height=50] ////////////////////////////////////////////////////////////////////// -The ldlm-gl-callback-request.png diagram resemgles this text +The ldlm-gl-callback-request.png diagram resembles this text art: LDLM_GL_CALLBACK: @@ -35,7 +35,7 @@ what lock is current, and what lock desired. <> image::ldlm-gl-callback-reply.png["LDLM_GL_CALLBACK Reply Packet Structure",height=50] ////////////////////////////////////////////////////////////////////// -The ldlm-gl-callback-reply.png diagram resemgles this text +The ldlm-gl-callback-reply.png diagram resembles this text art: LDLM_GL_CALLBACK: diff --git a/llog.txt b/llog.txt index ee0a9f4..c64c3f0 100644 --- a/llog.txt +++ b/llog.txt @@ -4,6 +4,6 @@ The Lustre Log Facility The Lustre log (llog) file may contain a number of different types of data structures, including redo records for uncommitted distributed -transactions such as unlink or ownership changes, configuration records -for targets and clients, or ChangeLog records to track changes to the -filesystem for external consumption, among others. +transactions such as unlink or ownership changes, configuration +records for targets and clients, or 'ChangeLog' records to track +changes to the file system for external consumption, among others. diff --git a/mds_connect.txt b/mds_connect.txt index 2b97ff5..e8019fc 100644 --- a/mds_connect.txt +++ b/mds_connect.txt @@ -35,7 +35,7 @@ MGS. 'client_uuid':: A string with the client's own UUID. This is also an <>. The target sets the 'exp_client_uuid' field of -its 'eport' structure to this value. +its 'export' structure to this value. 'lustre_handle':: See <>. This 'lustre_handle' is distinct from diff --git a/mds_getstatus.txt b/mds_getstatus.txt index f8d571f..2f9f305 100644 --- a/mds_getstatus.txt +++ b/mds_getstatus.txt @@ -2,7 +2,7 @@ RPC 40: MDS GETSTATUS - get the status from a target ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [[mds-getstatus-rpc]] -Get the attributes of the mountpoint of the file system. +Get the attributes of the mount point of the file system. .MDS_GETSTATUS Request Packet Structure image::mds-getstatus-request.png["MDS_GETSTATUS Request Packet Structure",height=50] @@ -43,7 +43,7 @@ RPC descriptor. See <>. See <>. In the reply message, the 'mdt_body' contains only the FID of the -filesystem ROOT in 'mbo_fid1'. The client can then use the returned +file system ROOT in 'mbo_fid1'. The client can then use the returned FID to fetch inode attributes for the root inode of the local -mountpoint. +mount point. diff --git a/mds_reint.txt b/mds_reint.txt index 57eae8f..6125e28 100644 --- a/mds_reint.txt +++ b/mds_reint.txt @@ -138,7 +138,7 @@ RPC descriptor. See <>. include::struct_mdt_rec_setxattr.txt[] -Retruning to the remaining buffers in the REINT_SETXATTR RPC we again +Returning to the remaining buffers in the REINT_SETXATTR RPC we again have several optional buffers followed by the 'ldlm_request'. 'lustre_capa':: diff --git a/mgs_connect.txt b/mgs_connect.txt index 8e9065c..899f77b 100644 --- a/mgs_connect.txt +++ b/mgs_connect.txt @@ -3,7 +3,7 @@ RPC 250: MGS CONNECT - Client connection to an MGS [[mgs-connect-rpc]] The general behavior of MGS_CONNECT RPCs closely resembles that of -OST_CONNECT RPCs (See <>) and MDS_CONNECt RPCs. The +OST_CONNECT RPCs (See <>) and MDS_CONNECT RPCs. The actual RPC's 'pb_opc' value will be different as are the names of the targets and the specific values in the 'obd_connect_data' structure. @@ -35,12 +35,12 @@ MGS. 'client_uuid':: A string with the client's own UUID. This is also a <>. The target sets the 'exp_client_uuid' field of -its 'eport' structure to this value. +its 'export' structure to this value. 'lustre_handle':: See <>. This 'lustre_handle' is distinct from the 'pb_handle' field in the 'ptlrpc_body'. This 'lustre_handle' -provied a unique 'cookie' to identify this client for this connection +provides a unique 'cookie' to identify this client for this connection attempt. After a disconnect, a subsequent connect RPC will have a different value. The target preserves this cookie in the 'exp_handle' field of its 'obd_export' structure for this client. In that way it diff --git a/mount.txt b/mount.txt index e3a0e44..574e866 100644 --- a/mount.txt +++ b/mount.txt @@ -5,7 +5,7 @@ Before any other interaction can take place between a client and a Lustre file system the client must 'mount' the file system, and Lustre services must already be started on the servers. A file system mount may be initiated via the 'mount()' system call, passing the -name of the MGS and Lustre filesystem to the kernel. The Lustre +name of the MGS and Lustre file system to the kernel. The Lustre client exchanges a series of messages with the servers, beginning with messages that retrieve the file system configuration <> from the management server (MGS). This provides the client with the identities diff --git a/ost_setattr.txt b/ost_setattr.txt index a91c303..ae23caf 100644 --- a/ost_setattr.txt +++ b/ost_setattr.txt @@ -29,9 +29,9 @@ final) buffer in an OST_SETATTR request message. include::struct_ost_body.txt[] The above discussion described the structure of the OST_SETATTR -request message. In this case the reply message sturcture looks much -the same. It uses the same to buffers, and oly changes their contents -to reflect that the message is a reply rather than a requsest. +request message. In this case the reply message structure looks much +the same. It uses the same to buffers, and only changes their contents +to reflect that the message is a reply rather than a request. .OST_SETATTR Reply Packet Structure image::ost-setattr-reply.png["OST_SETATTR Reply Packet Structure",height=50] diff --git a/setattr.txt b/setattr.txt index 587e985..842df4c 100644 --- a/setattr.txt +++ b/setattr.txt @@ -307,7 +307,7 @@ a lock on the resource, then before the OST can grant the lock to Client1 it has to interact with Client2. The OST sends an LDLM_BL_CALLBACK request to Client2 asking Client 2 to finish up with the lock it has. Client2 replies with a simple acknowledgment. When -Client2 is no longer using the lock it will send an LDLM_CANEL RPC to +Client2 is no longer using the lock it will send an LDLM_CANCEL RPC to the OST. At that point the OST grants the original request sending an LDLM_CP_CALLBACK request to Client1 to notify it. With that taken care of Client1 is finally able to issue the OST_PUNCH request that @@ -425,7 +425,7 @@ art: Its effect is to notify the OST that the lock has been returned. -*6 - The OST replies acknowleging the lock request.* +*6 - The OST replies acknowledging the lock request.* The ldlm_reply's lock descriptor acknowledges the request for an extent write lock without granting it ('l_req_mode' == LCK_PW, @@ -549,9 +549,9 @@ In this case the 'o_valid' field is 0x30403d: *11 - The OST acknowledges the LDLM_CANCEL (step 7) from Client2* The OST finishes up with the lock cancel (after having notified -Client1) by replying to Clietn2. This happens asynchronously with the +Client1) by replying to Client2. This happens asynchronously with the arrival of the OST_PUNCH request, and in <> it is shown -occuring after the OST_PUNCH, but that is not required. +occurring after the OST_PUNCH, but that is not required. .LDLM_CANCEL Reply Packet Structure image::ldlm-cancel-reply.png["LDLM_CANCEL Reply Packet Structure",height=50] @@ -566,7 +566,7 @@ The ldlm-cancel-reply.png diagram resembles this text art: ////////////////////////////////////////////////////////////////////// The LDLM_CANCEL reply is a so-called "empty" RPC. Its only purpose is -to acknowldge receipt of the LDLM_CANCEL request. +to acknowledge receipt of the LDLM_CANCEL request. *12 - The OST an OST_PUNCH reply.* diff --git a/statfs.txt b/statfs.txt index 336a168..bdc635b 100644 --- a/statfs.txt +++ b/statfs.txt @@ -37,7 +37,7 @@ created. The total number of objects is changed to preserve the difference 'f_files' - 'f_ffree', which is the current number of used objects. This is what "df" displays. -The number of OST free objects is divided by the filesystem-wide +The number of OST free objects is divided by the file-system-wide default stripe count (i.e. the expected number of OST objects used per MDT file), so that 'f_ffree' represents the expected minimum number of files that can be created at the current time. diff --git a/struct_lov_mds_md.txt b/struct_lov_mds_md.txt index 97d40c0..3e63119 100644 --- a/struct_lov_mds_md.txt +++ b/struct_lov_mds_md.txt @@ -9,7 +9,7 @@ about the layout of a file across the OSTs. There may be different types of layouts for different files, either 'lov_mds_md_v1' or 'lov_mds_md_v3' as of Lustre 2.7, though they are very similar in structure. In an intent request (as opposed to a reply and as yet -unimplemanted) it will modify the layout. It will not be included +unimplemented) it will modify the layout. It will not be included (zero length) in requests in current releases. [source,c] @@ -52,7 +52,7 @@ may also contain flags that modify the layout. LOV_PATTERN_F_HOLE means that there is a hole (missing object) within the layout, which is normally caused by corruption or loss of the file layout that had to be rebuilt by LFSCK. LOV_PATTERN_F_RELEASED is used by HSM to indicate that the -file data is not resident in the filesystem, but rather in an external +file data is not resident in the file system, but rather in an external archive, so the layout is only a stub that describes the layout to use when the file is restored. @@ -66,7 +66,7 @@ to the next stripe. The 'lmm_stripe_count' field gives how many OST objects the file is striped over. -The 'lmm_layout_gen' field is updated as the layout of the obeject is +The 'lmm_layout_gen' field is updated as the layout of the Object is updated. If the 'lmm_layout_gen' is modified, then clients can detect the layout has changed when refreshing the layout after having lost the layout lock. diff --git a/struct_lu_fid.txt b/struct_lu_fid.txt index 2b3a3d9..6a233a8 100644 --- a/struct_lu_fid.txt +++ b/struct_lu_fid.txt @@ -65,12 +65,12 @@ enum fid_seq { **** There are several reserved ranges of FID sequence values (summarized in the list above), to allow for interoperability with -older Lustre filesystems, to identify "well known" objects for +older Lustre file systems, to identify "well known" objects for internal or external use, as well as for future expansion. The 'FID_SEQ_OST_MDT0' (0x0) range is reserved for OST objects created -by MDT0 in non-DNE filesystems. Since all such OST objects used an -'f_seq' value of zero these FIDs are not unique across the filesystem, +by MDT0 in non-DNE file systems. Since all such OST objects used an +'f_seq' value of zero these FIDs are not unique across the file system, but the reservation of 'FID_SEQ_OST_MDT0' allows these FIDs to co-exist with other FIDs in the same 128-bit identifier space. @@ -87,13 +87,13 @@ as configuration logs and the ChangeLog. The 'FID_SEQ_IGIF' (0xb-0xffffffff) range is reserved for 'inode generation in FID' (IGIF) inodes allocated by MDSs before Lustre 2.0. This corresponds to the 4 billion maximum inode number that could be -allocated for such filesystems. The 'f_oid' field for IGIF FIDs +allocated for such file systems. The 'f_oid' field for IGIF FIDs contains the inode version number, and as such there is normally only a single object for each 'f_seq' value. The 'FID_SEQ_IDIF' (0x100000000-0x1fffffffff) range is reserved for mapping OST objects that were created by MDT0 using 'FID_SEQ_OST_MDT0' -to filesystem-unique FIDs. The second 16-bit field (bits 16-31) of the +to file-system-unique FIDs. The second 16-bit field (bits 16-31) of the 'f_seq' field contains the OST index (0-65535). The low 16-bit field (bits 0-15) of 'f_seq' contains the high (bits 32-47) bits of the OST object ID, and the 32-bit 'f_oid' field contains the low 32 bits of @@ -103,7 +103,7 @@ The 'FID_SEQ_LOCAL_FILE' (0x200000001) range is reserved for "well known" objects internal to the server and is not exposed to the network. The 'FID_SEQ_DOT_LUSTRE' (0x200000002) range is reserved for files -under the hidden ".lustre" directory in the root of the filesystem. +under the hidden ".lustre" directory in the root of the file system. The 'FID_SEQ_LOCAL_NAME' (0x200000003) range is reserved for objects internal to the server that are allocated by name. diff --git a/struct_mdt_body.txt b/struct_mdt_body.txt index 5554de7..59c7dd8 100644 --- a/struct_mdt_body.txt +++ b/struct_mdt_body.txt @@ -109,7 +109,7 @@ which hold such information as the resource's layout. The 'mbo_aclsize' field indicates the size of the POSIX access control lists (ACLs) in bytes. -The 'mbo_max_mdsize' field indicates the maximu size of the file layout, +The 'mbo_max_mdsize' field indicates the maximum size of the file layout, as described in <> The 'mbo_max_cookiesize' field is unused since Lustre 2.4. It diff --git a/struct_mdt_rec_reint.txt b/struct_mdt_rec_reint.txt index 2a443e1..b1f11ec 100644 --- a/struct_mdt_rec_reint.txt +++ b/struct_mdt_rec_reint.txt @@ -3,12 +3,12 @@ Generic MDS_REINT [[struct-mdt-rec-reint]] An 'mdt_rec_reint' structure specifies the generic form for MDS_REINT -requests. Each sub-operation, as defned by the 'rr_opcode' field, has +requests. Each sub-operation, as defined by the 'rr_opcode' field, has its own variant of this structure. Each variant has the same size as the generic 'mdt_rec_reint', but interprets its fields slightly differently. Note that in order for swabbing to take place correctly the sequence of field sizes must the same in every variant as it is in -the generic version (not just the overal size of the sturcture). +the generic version (not just the overall size of the structure). [source,c] ---- diff --git a/struct_mgs_config_body.txt b/struct_mgs_config_body.txt index 92857d7..e9e12aa 100644 --- a/struct_mgs_config_body.txt +++ b/struct_mgs_config_body.txt @@ -16,7 +16,7 @@ struct mgs_config_body { The 'mgs_config_body' structure has information identifying to the MGS which Lustre file system the client is requesting configuration information -from. 'mcb_name' contains the filesystem name (fsname). 'mcb_offset' +from. 'mcb_name' contains the file system name (fsname). 'mcb_offset' contains the next record number in the configuration llog to process (see <> for details), not the byte offset or bulk transfer units. 'mcb_bits' is the log2 of the units of minimum bulk transfer size, diff --git a/struct_obd_connect_data.txt b/struct_obd_connect_data.txt index 2e2a792..7dafd05 100644 --- a/struct_obd_connect_data.txt +++ b/struct_obd_connect_data.txt @@ -51,7 +51,7 @@ the flags for all features that it understands and intends to use (for example 'OBD_CONNECT_RDONLY' is optional depending on client mount options). The request also contains other fields that are only valid if the matching flag is set. The server replies in 'ocd_connect_flags' -with the subset of feature flags that it understands and intends to honour. +with the subset of feature flags that it understands and intends to honor. The server may set fields in the reply for mutually-understood features. The 'ocd_connect_flags' field encodes the connect flags giving the @@ -141,8 +141,8 @@ initializes the client's grant. See <>. If the OBD_CONNECT_INDEX flag is set then the 'ocd_index' field is valid. The 'ocd_index' value is set in a request to hold the LOV index of the OST or the LMV index of the MDT. The server's export for -the target holds the correct value, and if the client send a value -that does not match the server returns the -EBDF error. +the target holds the correct value, and if the client sends a value +that does not match the server returns the -EBADF error. If the OBD_CONNECT_BRW_SIZE flag is set then the 'ocd_brw_size' field is valid. The 'ocd_brw_size' value sets the maximum supported bulk @@ -185,7 +185,7 @@ Lustre 1.4 and is mandatory for MDS_CONNECT RPCs. If the OBD_CONNECT_GRANT_PARAM flag is set then the 'ocd_blocksize', 'ocd_inodespace', and 'ocd_grant_extent' fields are honored. A server reply uses the 'ocd_blocksize' value to inform the client of the log -base two of the size in bytes of the backend file system's blocks. +base two of the size in bytes of the OSD's blocks. A server reply uses the 'ocd_inodespace' value to inform the client of the log base two of the size of an inode. @@ -236,7 +236,7 @@ is honored. An OSS uses the 'ocd_maxbytes' value to inform the client of the maximum OST object size for this target. A file that is striped uniformly across multiple OST objects (RAID-0) cannot be larger than the number of stripes times the minimum 'ocd_maxbytes' value from any of its -consituent objects. +constituent objects. The additional space in the 'obd_connect_data' structure is unused and reserved for future use. @@ -249,24 +249,24 @@ read-only mode and the server honors that by denying any modification from this client. If the OBD_CONNECT_SRVLOCK flag is set then the client and server -support lockless IO. The server will take locks for client IO requests +support lock-less IO. The server will take locks for client IO requests with the OBD_BRW_SRVLOCK flag in the 'niobuf_remote' structure flags. This is used for Direct IO or when there is significant lock contention on a single OST object. The client takes no LDLM lock and delegates locking to the server. If the OBD_CONNECT_ACL flag is set then the server supports the ACL -mount option for its filesystem. If the server is mounted with ACL +mount option for its file system. If the server is mounted with ACL support but the client does not pass OBD_CONNECT_ACL then the client mount is refused. If the OBD_CONNECT_XATTR flag is set then the server supports user extended attributes. This is requested by the client if mounted with the appropriate mount option, but is enabled or disabled by the -mount options of the backend file system of MDT0000. +mount options of the OSD for MDT0000. If the OBD_CONNECT_TRUNCLOCK flag is set then the client and the -server support lockless truncate. This is realized in an OST_PUNCH RPC +server support lock-less truncate. This is realized in an OST_PUNCH RPC by setting the 'obdo' structure's 'o_flag' field to include the OBD_FL_SRVLOCK. In that circumstance the client takes no lock, and the server must take a lock on the resource while performing the truncate. @@ -293,7 +293,7 @@ error. If the OBD_CONNECT_CANCELSET is set then early batched cancels are enabled. The ELC (Early Lock Cancel) feature allows client locks to -be cancelled prior the cancellation callback if it is clear that lock +be canceled prior the cancellation callback if it is clear that lock is not needed anymore, for example after rename, after removing file or directory, link, etc. This can reduce amount of RPCs significantly. @@ -347,7 +347,7 @@ changes in replication state). The server will not grant a layout lock to the old clients that do not support this feature. If the OBD_CONNECT_64BITHASH is set then the client supports 64-bit -directory readdir cookie. The server will also use 64-bit hash mode +directory 'readdir' cookie. The server will also use 64-bit hash mode while working with ldiskfs. If the OBD_CONNECT_JOBSTATS is set then the client fills jobid in @@ -384,7 +384,7 @@ stripe' disposition for open request from the client. This helps to optimize a recovery of open requests. If the OBD_CONNECT_OPEN_BY_FID is set then an open by FID won't pack -the name in a request. This is used by HSM or other ChangeLog consumers +the name in a request. This is used by HSM or other 'ChangeLog' consumers for accessing objects by their FID via .lustre/fid/ instead of by name. If the OBD_CONNECT_MDS_MDS is set then the current connection is an @@ -406,7 +406,7 @@ store file size in file attributes, so client may get it directly from MDS avoiding glimpse request to OSTs. This feature was implemented as demo feature and wasn't enabled by default. Finally it was removed in Lustre 2.7 because it causes quite complex recovery cases to handle -with relatevely small benefits. +with relatively small benefits. The OBD_CONNECT_QUOTA64 was used prior Lustre 2.4 for quota purposes, it is obsoleted due to new quota design. @@ -422,7 +422,7 @@ If the OBD_CONNECT_EINPROGRESS is set then client handles -EINPROGRESS RPC error properly. The quota design requires that client must resend request with -EINPROGRESS error indefinitely, until successful completion or another error. This flag is set on both client and -server by default. Meanwhile this flag is not checked anywere, so does +server by default. Meanwhile this flag is not checked anywhere, so does nothing. If the OBD_CONNECT_FLOCK_OWNER is set then 1.8 clients has fixed flock diff --git a/struct_obd_export.txt b/struct_obd_export.txt index c7e1636..3f30728 100644 --- a/struct_obd_export.txt +++ b/struct_obd_export.txt @@ -104,7 +104,7 @@ target will increment the refcount. A reference by an LDLM lock that gets taken will increment the refcount. Callback invocations and replay also lead to incrementing the 'ref_count'. The next four fields - 'exp_rpc_count', exp_cb_count', and 'exp_replay_count', and -'exp_locks_count' - all subcategorize the 'exp_refcount'. The +'exp_locks_count' - all sub-categorize the 'exp_refcount'. The reference counter keeps the export alive while there are any users of that export. The reference counter is also used for debug purposes. Similarly, the 'exp_locks_list' and 'exp_locks_list_guard' @@ -116,11 +116,10 @@ are further debug info that list the actual locks accounted for in include::struct_obd_uuid.txt[] The 'exp_client_uuid' holds the UUID of the client connected to this -export. This UUID is randomly generated by the client and the same -UUID is used by the client for connecting to all servers, so that the -servers may identify the client amongst themselves if necessary. The -client's UID appears in the *_CONNECT message (See -<>, <>, and <>). +export. This UUID is randomly generated by the client, and the same +UUID is used by the client for connecting to all servers. The client's +UID appears in the *_CONNECT message (See <>, +<>, and <>). ////////////////////////////////////////////////////////////////////// ////vvvv @@ -174,7 +173,7 @@ deadlock detection. For those requests that initiate file system modifying transactions the request and its attendant locks need to be preserved until either -a) the client acknowleges recieving the reply, or b) the transaction +a) the client acknowledges receiving the reply, or b) the transaction has been committed locally. This ensures a request can be replayed in the event of a failure. The LDLM lock is being kept until one of these event occurs to prevent any other modifications of the same object. diff --git a/struct_obd_import.txt b/struct_obd_import.txt index 2ef6939..0432b0a 100644 --- a/struct_obd_import.txt +++ b/struct_obd_import.txt @@ -210,13 +210,13 @@ enumerated set of values: When the import is itself initialized it is set to LUSTRE_IMP_NEW. When a client initiates a *_CONNECT RPC it sets the state to LUSTRE_IMP_CONNECTING. Similarly, it sets the state to -LUSTRE_IMP_DISCON as it initiates a *_DISCONNECT RPC. Reciving the +LUSTRE_IMP_DISCON as it initiates a *_DISCONNECT RPC. Receiving the reply to the *DISCONNECT RPC will set the state to LUSTRE_IMP_CLOSED. When a (successful) *_CONNECT RPC reply arrives the state is set to LUSTRE_IMP_FULL. If a target signals a problem or a recovery condition then the state will proceed through the replay and recover states. When the target signals that the client connection is -invalid for some reaon the state will be set to +invalid for some reason the state will be set to LUSTRE_IMP_EVICTED. See <> and <>. ////////////////////////////////////////////////////////////////////// @@ -306,7 +306,7 @@ obvious from those short comments, reproduced here: | imp_delayed_recovery | VBR: imp in delayed recovery | imp_no_lock_replay | VBR: if gap was found then no lock replays | imp_vbr_failed | recovery by versions was failed -| imp_force_verify | force an immidiate ping +| imp_force_verify | force an immediate ping | imp_force_next_verify | force a scheduled ping | imp_pingable | target is pingable | imp_resend_replay | resend for replay diff --git a/struct_obd_statfs.txt b/struct_obd_statfs.txt index 6bc8670..2282668 100644 --- a/struct_obd_statfs.txt +++ b/struct_obd_statfs.txt @@ -97,8 +97,8 @@ In normal operation the 'os_state' value is returned as 0x0. If the OSD has a RAID configuration that is degraded or rebuilding the state is returned with the OS_STATE_DEGRADED (0x1) flag set. If the file system has been set to read-only, either manually at -mount or automatcially due to detected corruption of the underlying -target filesystem, then 'os_state' is returned with OS_STATE_READONLY (0x2) +mount or automatically due to detected corruption of the underlying +target file system, then 'os_state' is returned with OS_STATE_READONLY (0x2) set. The 'os_fprecreated' field counts the number of pre-created objects diff --git a/struct_ptlrpc_body.txt b/struct_ptlrpc_body.txt index eecb189..cc73ee9 100644 --- a/struct_ptlrpc_body.txt +++ b/struct_ptlrpc_body.txt @@ -54,7 +54,7 @@ will use that 'lustre_handle' (the 'pb_handle' field will be set to that value) to to gain access to their shared state. In subsequent RPC reply messages (after the *_CONNECT reply) the 'pb_handle' field is 0. The 'lustre_handle' is persistent across client reconnects to the -same instance of the server, but if the client unmounts the filesystem +same instance of the server, but if the client unmounts the file system or is evicted then it must re-connect as a new client, with a new 'lustre_handle'. @@ -266,7 +266,7 @@ and the value for each operation. | UPDATE_OBJ | 1000 |==== -The 'pb_status' field was already mentioned above in conjuction with +The 'pb_status' field was already mentioned above in conjunction with the 'pb_type' field in replies. In a request message 'pb_status' is set to the 'pid' of the process making the request. In a reply message, a zero indicates that the service successfully initiated the @@ -294,7 +294,7 @@ to operations that do modify the file system it is the target-unique, server-assigned transaction number for the client request. See <>. Upon receipt of the reply, the client copies this transaction number from 'pb_transno' of the reply to 'pb_transno' of -the saved request. If 'pb_transno' is larger than 'pb_last_commited' +the saved request. If 'pb_transno' is larger than 'pb_last_committed' (above) then the request has been processed at the target but is not yet committed to stable storage. The client must save the request for later resend to the server in case the target fails before the diff --git a/target.txt b/target.txt index c137802..0894042 100644 --- a/target.txt +++ b/target.txt @@ -5,7 +5,7 @@ Target Lustre servers manage permanent storage on behalf of the clients. That storage is divided into logical resources for management data, metadata (namespace and index data), and object storage. Each such -storage resource is called a target. Managment data is stored on a +storage resource is called a target. Management data is stored on a single management server (MGS) with a single target, also called the MGS. Namespace and index data are maintained on one or more metadata servers (MDSs), and each MDS may have several targets (MDTs). Object