From 5ee1fd2c329cb7daf33e4fc9bad1ee475f131051 Mon Sep 17 00:00:00 2001 From: Kefu Chai Date: Tue, 18 Sep 2018 11:19:18 +0800 Subject: [PATCH] doc: fix typos Signed-off-by: Kefu Chai --- README.FreeBSD | 6 +++--- doc/architecture.rst | 2 +- doc/cephfs/cache-size-limits.rst | 2 +- doc/cephfs/client-auth.rst | 2 +- doc/cephfs/mds-config-ref.rst | 2 +- doc/cephfs/multimds.rst | 2 +- doc/cephfs/upgrading.rst | 2 +- doc/dev/blkin.rst | 2 +- doc/dev/cephfs-snapshots.rst | 2 +- doc/dev/config.rst | 2 +- doc/dev/mds_internals/data-structures.rst | 2 +- doc/dev/osd_internals/erasure_coding/proposals.rst | 8 ++++---- doc/dev/osd_internals/last_epoch_started.rst | 2 +- doc/dev/osd_internals/log_based_pg.rst | 2 +- doc/dev/osd_internals/osd_throttles.rst | 2 +- doc/dev/rados-client-protocol.rst | 4 ++-- doc/dev/radosgw/s3_compliance.rst | 4 ++-- doc/glossary.rst | 2 +- doc/mgr/dashboard.rst | 2 +- doc/mgr/influx.rst | 2 +- doc/mgr/orchestrator_modules.rst | 2 +- doc/rados/configuration/mon-config-ref.rst | 2 +- doc/rados/configuration/pool-pg-config-ref.rst | 2 +- doc/rados/operations/erasure-code-jerasure.rst | 2 +- doc/rados/operations/erasure-code-lrc.rst | 4 ++-- doc/rados/operations/monitoring-osd-pg.rst | 2 +- doc/radosgw/elastic-sync-module.rst | 2 +- doc/releases/cuttlefish.rst | 6 +++--- doc/start/quick-ceph-deploy.rst | 2 +- src/doc/caching.txt | 4 ++-- src/doc/killpoints.txt | 2 +- src/doc/mds_locks.txt | 6 +++--- src/pybind/mgr/dashboard/HACKING.rst | 12 ++++++------ 33 files changed, 51 insertions(+), 51 deletions(-) diff --git a/README.FreeBSD b/README.FreeBSD index f1a56118dfe..a3193f7d23e 100644 --- a/README.FreeBSD +++ b/README.FreeBSD @@ -2,7 +2,7 @@ Last updated: 2017-04-08 The FreeBSD build will build most of the tools in Ceph. -Note that the (kernel) RBD dependant items will not work +Note that the (kernel) RBD dependent items will not work I started looking into Ceph, because the HAST solution with CARP and ggate did not really do what I was looking for. But I'm aiming for @@ -70,7 +70,7 @@ Build Prerequisites 11-RELEASE will also work. And Clang is at 3.8.0. It uses the CLANG toolset that is available, 3.7 is no longer tested, but was working when that was with 11-CURRENT. - Clang 3.4 (on 10.2-STABLE) does not have all required capabilites to + Clang 3.4 (on 10.2-STABLE) does not have all required capabilities to compile everything The following setup will get things running for FreeBSD: @@ -158,5 +158,5 @@ Task to do: with all the packages FreeBSD already has in place. Lots of minute details to figure out - - Design a vitual disk implementation that can be used with behyve and + - Design a virtual disk implementation that can be used with behyve and attached to an RBD image. diff --git a/doc/architecture.rst b/doc/architecture.rst index fb6e9c31bf1..0aa1686d922 100644 --- a/doc/architecture.rst +++ b/doc/architecture.rst @@ -1436,7 +1436,7 @@ Ceph Clients include a number of service interfaces. These include: - **Filesystem**: The :term:`Ceph Filesystem` (CephFS) service provides a POSIX compliant filesystem usable with ``mount`` or as - a filesytem in user space (FUSE). + a filesystem in user space (FUSE). Ceph can run additional instances of OSDs, MDSs, and monitors for scalability and high availability. The following diagram depicts the high-level diff --git a/doc/cephfs/cache-size-limits.rst b/doc/cephfs/cache-size-limits.rst index 90cf8ade760..511a2e498fb 100644 --- a/doc/cephfs/cache-size-limits.rst +++ b/doc/cephfs/cache-size-limits.rst @@ -19,4 +19,4 @@ Be aware that the cache limit is not a hard limit. Potential bugs in the CephFS The memory tracking used is currently imprecise by a constant factor. This will be addressed in http://tracker.ceph.com/issues/22599. MDS deployments with large `mds_cache_memory_limit` (64GB+) should underallocate RAM to - accomodate. + accommodate. diff --git a/doc/cephfs/client-auth.rst b/doc/cephfs/client-auth.rst index bd0ad1326a8..39513748e43 100644 --- a/doc/cephfs/client-auth.rst +++ b/doc/cephfs/client-auth.rst @@ -56,7 +56,7 @@ the shell. See `User Management - Add a User to a Keyring`_. for additional details on user management -To restrict a client to the specfied sub-directory only, we mention the specified +To restrict a client to the specified sub-directory only, we mention the specified directory while mounting using the following syntax. :: ./ceph-fuse -n client.*client_name* *mount_path* -r *directory_to_be_mounted* diff --git a/doc/cephfs/mds-config-ref.rst b/doc/cephfs/mds-config-ref.rst index 2f7eb3758a8..000f1ecc822 100644 --- a/doc/cephfs/mds-config-ref.rst +++ b/doc/cephfs/mds-config-ref.rst @@ -279,7 +279,7 @@ ``mds bal fragment interval`` -:Description: The delay (in seconds) between a fragment being elegible for split +:Description: The delay (in seconds) between a fragment being eligible for split or merge and executing the fragmentation change. :Type: 32-bit Integer :Default: ``5`` diff --git a/doc/cephfs/multimds.rst b/doc/cephfs/multimds.rst index a60ef39e5a7..ac4b434321d 100644 --- a/doc/cephfs/multimds.rst +++ b/doc/cephfs/multimds.rst @@ -123,7 +123,7 @@ to. A default value of ``-1`` indicates the directory is not pinned. A directory's export pin is inherited from its closest parent with a set export pin. In this way, setting the export pin on a directory affects all of its -children. However, the parents pin can be overriden by setting the child +children. However, the parents pin can be overridden by setting the child directory's export pin. For example: :: diff --git a/doc/cephfs/upgrading.rst b/doc/cephfs/upgrading.rst index bfc29090814..a7cb35d328e 100644 --- a/doc/cephfs/upgrading.rst +++ b/doc/cephfs/upgrading.rst @@ -7,7 +7,7 @@ assertions or other faults due to incompatible messages or other functional differences. For this reason, it's necessary during any cluster upgrade to reduce the number of active MDS for a file system to one first so that two active MDS do not communicate with different versions. Further, it's also -necessary to take standbys offline as any new CompatSet flags will propogate +necessary to take standbys offline as any new CompatSet flags will propagate via the MDSMap to all MDS and cause older MDS to suicide. The proper sequence for upgrading the MDS cluster is: diff --git a/doc/dev/blkin.rst b/doc/dev/blkin.rst index 0f61ed473be..f8daebd32b3 100644 --- a/doc/dev/blkin.rst +++ b/doc/dev/blkin.rst @@ -109,7 +109,7 @@ You may want to check that ceph is up.:: ./ceph status -Now put something in usin rados, check that it made it, get it back, and remove it.:: +Now put something in using rados, check that it made it, get it back, and remove it.:: ./ceph osd pool create test-blkin 8 ./rados put test-object-1 ./vstart.sh --pool=test-blkin diff --git a/doc/dev/cephfs-snapshots.rst b/doc/dev/cephfs-snapshots.rst index f1d00835353..509b5ff3f70 100644 --- a/doc/dev/cephfs-snapshots.rst +++ b/doc/dev/cephfs-snapshots.rst @@ -78,7 +78,7 @@ Generating a SnapContext ------------------------ A RADOS `SnapContext` consists of a snapshot sequence ID (`snapid`) and all the snapshot IDs that an object is already part of. To generate that list, we -combine `snapids` associated with the SnapRealm and all vaild `snapids` in +combine `snapids` associated with the SnapRealm and all valid `snapids` in `past_parent_snaps`. Stale `snapids` are filtered out by SnapClient's cached effective snapshots. diff --git a/doc/dev/config.rst b/doc/dev/config.rst index 50be81322f2..5b620b2fe8c 100644 --- a/doc/dev/config.rst +++ b/doc/dev/config.rst @@ -122,7 +122,7 @@ Default values There is a default value for every config option. In some cases, there may also be a *daemon default* that only applies to code that declares itself -as a daemon (in thise case, the regular default only applies to non-daemons). +as a daemon (in this case, the regular default only applies to non-daemons). Safety ------ diff --git a/doc/dev/mds_internals/data-structures.rst b/doc/dev/mds_internals/data-structures.rst index f06727166fc..c77175a16fc 100644 --- a/doc/dev/mds_internals/data-structures.rst +++ b/doc/dev/mds_internals/data-structures.rst @@ -36,7 +36,7 @@ quite large. Please be careful if you want to add new fields to them. *OpenFileTable* Open file table tracks open files and their ancestor directories. Recovering - MDS can easily get open files' pathes, significantly reducing the time of + MDS can easily get open files' paths, significantly reducing the time of loading inodes for open files. Each entry in the table corresponds to an inode, it records linkage information (parent inode and dentry name) of the inode. MDS can constructs the inode's path by recursively lookup parent inode's linkage. diff --git a/doc/dev/osd_internals/erasure_coding/proposals.rst b/doc/dev/osd_internals/erasure_coding/proposals.rst index 52f98e87d86..caba487d216 100644 --- a/doc/dev/osd_internals/erasure_coding/proposals.rst +++ b/doc/dev/osd_internals/erasure_coding/proposals.rst @@ -77,7 +77,7 @@ object keys. Perhaps some modeling here can help resolve this issue. The data of the temporary object wants to be located as close to the data of the base object as possible. This may be best performed by adding a new ObjectStore creation primitive that takes the base -object as an addtional parameter that is a hint to the allocator. +object as an additional parameter that is a hint to the allocator. Sam: I think that the short lived thing may be a red herring. We'll be updating the donor and primary objects atomically, so it seems like @@ -224,7 +224,7 @@ code necessarily has designated parity shards which see every write might be desirable to rotate the shards based on object hash). Even if you chose to designate a shard as witnessing all writes, the pg might be degraded with that particular shard missing. This is a bit -tricky, currently reads and writes implicitely return the most recent +tricky, currently reads and writes implicitly return the most recent version of the object written. On reads, we'd have to read K shards to answer that question. We can get around that by adding a "don't tell me the current version" flag. Writes are more problematic: we @@ -254,7 +254,7 @@ user version assert on ec for now (I think? Only user is rgw bucket indices iirc, and those will always be on replicated because they use omap). -We can avoid (1) by maintaining the missing set explicitely. It's +We can avoid (1) by maintaining the missing set explicitly. It's already possible for there to be a missing object without a corresponding log entry (Consider the case where the most recent write is to an object which has not been updated in weeks. If that write @@ -355,7 +355,7 @@ though. It's a bit silly since all "shards" see all writes, but it would still let us implement and partially test the augmented backfill code as well as the extra pg log entry fields -- this depends on the explicit pg log entry branch having already merged. It's not entirely -clear to me that this one is worth doing seperately. It's enough code +clear to me that this one is worth doing separately. It's enough code that I'd really prefer to get it done independently, but it's also a fair amount of scaffolding that will be later discarded. diff --git a/doc/dev/osd_internals/last_epoch_started.rst b/doc/dev/osd_internals/last_epoch_started.rst index 586f9f7b125..8ed5c980a73 100644 --- a/doc/dev/osd_internals/last_epoch_started.rst +++ b/doc/dev/osd_internals/last_epoch_started.rst @@ -26,7 +26,7 @@ Thus, the minimum last_update across all infos with info.last_epoch_started >= MAX(history.last_epoch_started) must be an upper bound on writes reported as committed to the client. -We update info.last_epoch_started with the intial activation message, +We update info.last_epoch_started with the initial activation message, but we only update history.last_epoch_started after the new info.last_epoch_started is persisted (possibly along with the first write). This ensures that we do not require an osd with the most diff --git a/doc/dev/osd_internals/log_based_pg.rst b/doc/dev/osd_internals/log_based_pg.rst index 4f4524f8d88..51eb8278b3e 100644 --- a/doc/dev/osd_internals/log_based_pg.rst +++ b/doc/dev/osd_internals/log_based_pg.rst @@ -27,7 +27,7 @@ writes on overlapping regions), we might as well serialize writes on the whole PG since it lets us represent the current state of the PG using two numbers: the epoch of the map on the primary in which the most recent write started (this is a bit stranger than it might seem -since map distribution itself is asyncronous -- see Peering and the +since map distribution itself is asynchronous -- see Peering and the concept of interval changes) and an increasing per-pg version number -- this is referred to in the code with type eversion_t and stored as pg_info_t::last_update. Furthermore, we maintain a log of "recent" diff --git a/doc/dev/osd_internals/osd_throttles.rst b/doc/dev/osd_internals/osd_throttles.rst index 6739bd9ea5a..ee98d24850c 100644 --- a/doc/dev/osd_internals/osd_throttles.rst +++ b/doc/dev/osd_internals/osd_throttles.rst @@ -12,7 +12,7 @@ included in FileStore as FileStore::wbthrottle. The intention is to bound the amount of outstanding IO we need to do to flush the journal. At the same time, we don't want to necessarily do it inline in case we might be able to combine several IOs on the same object close together -in time. Thus, in FileStore::_write, we queue the fd for asyncronous +in time. Thus, in FileStore::_write, we queue the fd for asynchronous flushing and block in FileStore::_do_op if we have exceeded any hard limits until the background flusher catches up. diff --git a/doc/dev/rados-client-protocol.rst b/doc/dev/rados-client-protocol.rst index da3d73dae6f..920c65f3983 100644 --- a/doc/dev/rados-client-protocol.rst +++ b/doc/dev/rados-client-protocol.rst @@ -77,9 +77,9 @@ A backoff request has four properties: #. hobject_t end There are two types of backoff: a *PG* backoff will plug all requests -targetting an entire PG at the client, as described by a range of the +targeting an entire PG at the client, as described by a range of the hash/hobject_t space [begin,end), while an *object* backoff will plug -all requests targetting a single object (begin == end). +all requests targeting a single object (begin == end). When the client receives a *block* backoff message, it is now responsible for *not* sending any requests for hobject_ts described by diff --git a/doc/dev/radosgw/s3_compliance.rst b/doc/dev/radosgw/s3_compliance.rst index b6b0d854307..50aeda36a31 100644 --- a/doc/dev/radosgw/s3_compliance.rst +++ b/doc/dev/radosgw/s3_compliance.rst @@ -166,7 +166,7 @@ S3 Documentation reference : http://docs.aws.amazon.com/AmazonS3/latest/API/REST +--------+------------------------+------------+------------------------------------------------------------------------------------------------------------+-------------+ | GET | Bucket requestPayment | No | | | +--------+------------------------+------------+------------------------------------------------------------------------------------------------------------+-------------+ -| GET | Bucket versionning | No | | | +| GET | Bucket versioning | No | | | +--------+------------------------+------------+------------------------------------------------------------------------------------------------------------+-------------+ | GET | Bucket website | No | | | +--------+------------------------+------------+------------------------------------------------------------------------------------------------------------+-------------+ @@ -209,7 +209,7 @@ S3 Documentation reference : http://docs.aws.amazon.com/AmazonS3/latest/API/REST +--------+------------------------+------------+------------------------------------------------------------------------------------------------------------+-------------+ | PUT | Bucket requestPayment | No | | | +--------+------------------------+------------+------------------------------------------------------------------------------------------------------------+-------------+ -| PUT | Bucket versionning | No | | | +| PUT | Bucket versioning | No | | | +--------+------------------------+------------+------------------------------------------------------------------------------------------------------------+-------------+ | PUT | Bucket website | No | | | +--------+------------------------+------------+------------------------------------------------------------------------------------------------------------+-------------+ diff --git a/doc/glossary.rst b/doc/glossary.rst index 18f7156ec6a..ce86daf1cba 100644 --- a/doc/glossary.rst +++ b/doc/glossary.rst @@ -103,7 +103,7 @@ reflect either technical terms or legacy ways of referring to Ceph systems. ``fsid`` term is used interchangeably with ``uuid`` OSD uuid - Just like the OSD fsid, this is the OSD unique identifer and is used + Just like the OSD fsid, this is the OSD unique identifier and is used interchangeably with ``fsid`` bluestore diff --git a/doc/mgr/dashboard.rst b/doc/mgr/dashboard.rst index 8b9ae7628c8..a1e7d35e4e6 100644 --- a/doc/mgr/dashboard.rst +++ b/doc/mgr/dashboard.rst @@ -385,7 +385,7 @@ User accounts are also associated with a set of roles that define which dashboard functionality can be accessed by the user. The Dashboard functionality/modules are grouped within a *security scope*. -Security scopes are predefined and static. The current avaliable security +Security scopes are predefined and static. The current available security scopes are: - **hosts**: includes all features related to the ``Hosts`` menu diff --git a/doc/mgr/influx.rst b/doc/mgr/influx.rst index 7fefcff5e9d..7434b4d8bcc 100644 --- a/doc/mgr/influx.rst +++ b/doc/mgr/influx.rst @@ -62,7 +62,7 @@ Additional optional configuration settings are: Debugging --------- -By default, a few debugging statments as well as error statements have been set to print in the log files. Users can add more if necessary. +By default, a few debugging statements as well as error statements have been set to print in the log files. Users can add more if necessary. To make use of the debugging option in the module: - Add this to the ceph.conf file.:: diff --git a/doc/mgr/orchestrator_modules.rst b/doc/mgr/orchestrator_modules.rst index 93d4844a5c8..265e312dde6 100644 --- a/doc/mgr/orchestrator_modules.rst +++ b/doc/mgr/orchestrator_modules.rst @@ -17,7 +17,7 @@ provides the ability to discover devices and create Ceph services. This includes external projects such as ceph-ansible, DeepSea, and Rook. An *orchestrator module* is a ceph-mgr module (:ref:`mgr-module-dev`) -which implements common managment operations using a particular +which implements common management operations using a particular orchestrator. Orchestrator modules subclass the ``Orchestrator`` class: this class is diff --git a/doc/rados/configuration/mon-config-ref.rst b/doc/rados/configuration/mon-config-ref.rst index ce91ecfba4e..b144d440f83 100644 --- a/doc/rados/configuration/mon-config-ref.rst +++ b/doc/rados/configuration/mon-config-ref.rst @@ -1197,7 +1197,7 @@ Miscellaneous :Description: Largest number of PGs per "involved" OSD to let split create. When we increase the ``pg_num`` of a pool, the placement groups - will be splitted on all OSDs serving that pool. We want to avoid + will be split on all OSDs serving that pool. We want to avoid extreme multipliers on PG splits. :Type: Integer :Default: 300 diff --git a/doc/rados/configuration/pool-pg-config-ref.rst b/doc/rados/configuration/pool-pg-config-ref.rst index 2b438313598..31e2a0fd828 100644 --- a/doc/rados/configuration/pool-pg-config-ref.rst +++ b/doc/rados/configuration/pool-pg-config-ref.rst @@ -6,7 +6,7 @@ When you create pools and set the number of placement groups for the pool, Ceph uses default values when you don't specifically override the defaults. **We -recommend** overridding some of the defaults. Specifically, we recommend setting +recommend** overriding some of the defaults. Specifically, we recommend setting a pool's replica size and overriding the default number of placement groups. You can specifically set these values when running `pool`_ commands. You can also override the defaults by adding new ones in the ``[global]`` section of your diff --git a/doc/rados/operations/erasure-code-jerasure.rst b/doc/rados/operations/erasure-code-jerasure.rst index be626eca145..878bcac5cb6 100644 --- a/doc/rados/operations/erasure-code-jerasure.rst +++ b/doc/rados/operations/erasure-code-jerasure.rst @@ -63,7 +63,7 @@ Where: ``packetsize={bytes}`` :Description: The encoding will be done on packets of *bytes* size at - a time. Chosing the right packet size is difficult. The + a time. Choosing the right packet size is difficult. The *jerasure* documentation contains extensive information on this topic. diff --git a/doc/rados/operations/erasure-code-lrc.rst b/doc/rados/operations/erasure-code-lrc.rst index 6b8a94edc5f..eeb07a38575 100644 --- a/doc/rados/operations/erasure-code-lrc.rst +++ b/doc/rados/operations/erasure-code-lrc.rst @@ -159,7 +159,7 @@ Low level plugin configuration The sum of **k** and **m** must be a multiple of the **l** parameter. The low level configuration parameters do not impose such a -restriction and it may be more convienient to use it for specific +restriction and it may be more convenient to use it for specific purposes. It is for instance possible to define two groups, one with 4 chunks and another with 3 chunks. It is also possible to recursively define locality sets, for instance datacenters and racks into @@ -280,7 +280,7 @@ The steps found in the layers description:: step 3 ____cDDD are applied in order. For instance, if a 4K object is encoded, it will -first go thru *step 1* and be divided in four 1K chunks (the four +first go through *step 1* and be divided in four 1K chunks (the four uppercase D). They are stored in the chunks 2, 3, 6 and 7, in order. From these, two coding chunks are calculated (the two lowercase c). The coding chunks are stored in the chunks 1 and 5, respectively. diff --git a/doc/rados/operations/monitoring-osd-pg.rst b/doc/rados/operations/monitoring-osd-pg.rst index 5f5d763bf40..11f5846e845 100644 --- a/doc/rados/operations/monitoring-osd-pg.rst +++ b/doc/rados/operations/monitoring-osd-pg.rst @@ -413,7 +413,7 @@ Stale While Ceph uses heartbeats to ensure that hosts and daemons are running, the ``ceph-osd`` daemons may also get into a ``stuck`` state where they are not reporting statistics in a timely manner (e.g., a temporary network fault). By -default, OSD daemons report their placement group, up thru, boot and failure +default, OSD daemons report their placement group, up through, boot and failure statistics every half second (i.e., ``0.5``), which is more frequent than the heartbeat thresholds. If the **Primary OSD** of a placement group's acting set fails to report to the monitor or if other OSDs have reported the primary OSD diff --git a/doc/radosgw/elastic-sync-module.rst b/doc/radosgw/elastic-sync-module.rst index 3878fe081e4..e06cbb66d8a 100644 --- a/doc/radosgw/elastic-sync-module.rst +++ b/doc/radosgw/elastic-sync-module.rst @@ -146,7 +146,7 @@ than string. POST /{bucket}?mdsearch x-amz-meta-search: [, ...] -Multiple metadata fields must be comma seperated, a type can be forced for a +Multiple metadata fields must be comma separated, a type can be forced for a field with a `;`. The currently allowed types are string(default), integer and date diff --git a/doc/releases/cuttlefish.rst b/doc/releases/cuttlefish.rst index a9e28c98335..28ab8c7e0c2 100644 --- a/doc/releases/cuttlefish.rst +++ b/doc/releases/cuttlefish.rst @@ -354,7 +354,7 @@ Please see `Upgrading from Bobtail to Cuttlefish`_ for details. * The sysvinit script now uses the ceph.conf file on the remote host when starting remote daemons via the '-a' option. Note that if '-a' - is used in conjuction with '-c path', the path must also be present + is used in conjunction with '-c path', the path must also be present on the remote host (it is not copied to a temporary file, as it was previously). @@ -472,7 +472,7 @@ Notable changes from v0.56 "Bobtail" * mds: many fixes (Yan Zheng) * mds: misc bug fixes with clustered MDSs and failure recovery * mds: misc bug fixes with readdir -* mds: new encoding for all data types (to allow forward/backward compatbility) (Greg Farnum) +* mds: new encoding for all data types (to allow forward/backward compatibility) (Greg Farnum) * mds: store and update backpointers/traces on directory, file objects (Sam Lang) * mon: 'osd crush add|link|unlink|add-bucket ...' commands * mon: ability to tune leveldb @@ -665,7 +665,7 @@ Notable Changes * radosgw: fix object copy onto self (Yehuda Sadeh) * radosgw: ACL grants in headers (Caleb Miles) * radosgw: ability to listen to fastcgi via a port (Guilhem Lettron) - * mds: new encoding for all data types (to allow forward/backward compatbility) (Greg Farnum) + * mds: new encoding for all data types (to allow forward/backward compatibility) (Greg Farnum) * mds: fast failover between MDSs (enforce unique mds names) * crush: ability to create, remove rules via CLI * many many cleanups (Danny Al-Gaaf) diff --git a/doc/start/quick-ceph-deploy.rst b/doc/start/quick-ceph-deploy.rst index bb2bcc19f4b..91a7d11fe2e 100644 --- a/doc/start/quick-ceph-deploy.rst +++ b/doc/start/quick-ceph-deploy.rst @@ -201,7 +201,7 @@ A Ceph Storage Cluster requires at least one Ceph Monitor and Ceph Manager to run. For high availability, Ceph Storage Clusters typically run multiple Ceph Monitors so that the failure of a single Ceph Monitor will not bring down the Ceph Storage Cluster. Ceph uses the -Paxos algorithm, which requires a majority of monitors (i.e., greather +Paxos algorithm, which requires a majority of monitors (i.e., greater than *N/2* where *N* is the number of monitors) to form a quorum. Odd numbers of monitors tend to be better, although this is not required. diff --git a/src/doc/caching.txt b/src/doc/caching.txt index 31570cc874b..58d453175c9 100644 --- a/src/doc/caching.txt +++ b/src/doc/caching.txt @@ -161,7 +161,7 @@ pins) to be migrated to a different MDS node. Pins can be placed on both inodes and directories. Auth pins can only exist for authoritative metadata, because they are -only created if the object is authoritative, and their presense +only created if the object is authoritative, and their presence prevents the migration of authority. @@ -197,7 +197,7 @@ CACHE EXPIRATION FOR EXPORTING SUBTREES Cache expiration messages that are received for a subtree that is being exported are either deferred or handled immediately, based on -the sender and reciever states. The importing MDS will always defer until +the sender and receiver states. The importing MDS will always defer until after the export finishes, because the import could fail. The exporting MDS processes the expire UNLESS the expiring MDS does not know about the export or the exporting MDS is no longer auth. diff --git a/src/doc/killpoints.txt b/src/doc/killpoints.txt index 1cd2bb6ba6f..0813386bd8e 100644 --- a/src/doc/killpoints.txt +++ b/src/doc/killpoints.txt @@ -16,7 +16,7 @@ mds_kill_mdstable_at: mds_kill_export_at: 1: After moving to STATE_EXPORTING 2: After sending MExportDirDiscover -3: After recieving MExportDirDiscoverAck and auth_unpin'ing. +3: After receiving MExportDirDiscoverAck and auth_unpin'ing. 4: After sending MExportDirPrep 5: After receiving MExportDirPrepAck 6: After sending out MExportDirNotify to all replicas diff --git a/src/doc/mds_locks.txt b/src/doc/mds_locks.txt index f41a89a9b31..d89cc22af4c 100644 --- a/src/doc/mds_locks.txt +++ b/src/doc/mds_locks.txt @@ -30,7 +30,7 @@ recover dist request state on rejoin: - locked: prevents dn read - on auth --> grab _all_ path pins at onces; hold none while waiting. +-> grab _all_ path pins at once; hold none while waiting. -> grab xlocks in order. --- auth_pin = pin to authority, on *dir, *in @@ -41,7 +41,7 @@ recover dist request state on rejoin: -> blocking on auth_pins is dangerous. _never_ block if we are holding other auth_pins on the same node (subtree?). -> grab _all_ auth pins at once; hold none while waiting. ---- hard/file_wrlock = exlusive lock on inode content +--- hard/file_wrlock = exclusive lock on inode content - prevents inode read - on auth @@ -54,7 +54,7 @@ ORDERING - order inodes on (ino); - need to order both read and write locks, esp with dentries. so, if we need to lock /usr/bin/foo with read on usr and bin and xwrite on foo, we need to acquire all of those locks using the same ordering. - on same host, we can be 'nice' and check lockability of all items, then lock all, and drop everything while waiting. (actually, is there any use to this?) - - on mutiple hosts, we need to use full ordering (at least as things separate across host boundaries). and if needed lock set changes (such that the order of already acquired locks changes), we need to drop those locks and start over. + - on multiple hosts, we need to use full ordering (at least as things separate across host boundaries). and if needed lock set changes (such that the order of already acquired locks changes), we need to drop those locks and start over. - how do auth pins fit into all this? - auth pin on xlocks only. no need on read locks. diff --git a/src/pybind/mgr/dashboard/HACKING.rst b/src/pybind/mgr/dashboard/HACKING.rst index df41408f906..3c9f588f916 100644 --- a/src/pybind/mgr/dashboard/HACKING.rst +++ b/src/pybind/mgr/dashboard/HACKING.rst @@ -63,8 +63,8 @@ Run ``npm run build`` to build the project. The build artifacts will be stored in the ``dist/`` directory. Use the ``-prod`` flag for a production build. Navigate to ``https://localhost:8443``. -Formating TS and SCSS files -~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Formatting TS and SCSS files +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We use `Prettier `_ to automatically format TS and SCSS files. @@ -357,7 +357,7 @@ path parameters, query parameters, or body parameters. For ``GET`` and ``DELETE`` methods, the method's non-optional parameters are considered path parameters by default. Optional parameters are considered -query parameters. By specifing the ``query_parameters`` in the endpoint +query parameters. By specifying the ``query_parameters`` in the endpoint decorator it is possible to make a non-optional parameter to be a query parameter. @@ -411,7 +411,7 @@ the ``post`` method case. Defining path parameters in endpoints's URLs using python methods's parameters is very easy but it is still a bit strict with respect to the position of these parameters in the URL structure. -Sometimes we may want to explictly define a URL scheme that +Sometimes we may want to explicitly define a URL scheme that contains path parameters mixed with static parts of the URL. Our controller infrastructure also supports the declaration of URL paths with explicit path parameters at both the controller level and method level. @@ -728,7 +728,7 @@ The value of the class attribute is a pair composed by the default value for tha setting, and the python type of the value. By declaring the ``ADMIN_EMAIL_ADDRESS`` class attribute, when you restart the -dashboard plugin, you will atomatically gain two additional CLI commands to +dashboard plugin, you will automatically gain two additional CLI commands to get and set that setting:: $ ceph dashboard get-admin-email-address @@ -886,7 +886,7 @@ additional parameter called ``executor``. The full method signature of The ``TaskExecutor`` class is responsible for code that executes a given task -function, and defines three methods that can be overriden by +function, and defines three methods that can be overridden by subclasses:: def init(self, task)