Update documentation (#794)

Author: Yonghui-Lee

docs/source/code-of-conduct.rst

@@ -42,8 +42,8 @@ incident to the fsspec core team.
 Reporting
 ---------
 
-If you believe someone is violating theCode of Conduct we ask that you report it
-to the  Project by emailing community@anaconda.com. All reports will be kept
+If you believe someone is violating the Code of Conduct we ask that you report it
+to the Project by emailing community@anaconda.com. All reports will be kept
 confidential. In some cases we may determine that a public statement will need
 to be made. If that's the case, the identities of all victims and reporters
 will remain confidential unless those individuals instruct us otherwise.
@@ -93,7 +93,7 @@ Following this declaration, they will not be provided with any confidential
 details from the reporter.
 
 Once the working group has a complete account of the events they will make a
-decision as to how to response. Responses may include:
+decision as to how to respond. Responses may include:
 
 - Nothing (if we determine no violation occurred).
 - A private reprimand from the working group to the individual(s) involved.

docs/source/fuse.rst

@@ -49,7 +49,7 @@ expect exceptions.
 Furthermore:
 
    - although mutation operations tentatively work, you should not at the moment
-     depend on gcsfuse as a reliable system that won't loose your data.
+     depend on gcsfuse as a reliable system that won't lose your data.
 
    - permissions on GCS are complicated, so all files will be shown as fully-open
      0o777, regardless of state. If a read fails, you likely don't have the right

docs/source/hns_buckets.rst

@@ -53,7 +53,7 @@ Important Differences to Keep in Mind
 While ``gcsfs`` aims to abstract the differences via the ``fsspec`` API, you should be aware of standard HNS limitations imposed by the Google Cloud Storage API:
 
 1. **Implicit directories:** In standard GCS, you can create an object ``a/b/c.txt`` without the directories ``a/`` or ``a/b/`` physically existing. In HNS, the parent folder resources must exist (or be created) before the object can be written. ``gcsfs`` handles parent folder creation natively under the hood.
-2. **``mkdir`` behavior:** Previously, in a flat namespace, calling ``mkdir`` on a path could only ensure the underlying bucket exists. With HNS enabled, calling ``mkdir`` will create an actual folder resource in GCS. Furthermore, if you want to create nested folders (eg: bucket/a/b/c/d) pass ``create_parents=True``, it will physically create all intermediate folder resources along the specified path.
+2. **``mkdir`` behavior:** Previously, in a flat namespace, calling ``mkdir`` on a path could only ensure the underlying bucket exists. With HNS enabled, calling ``mkdir`` will create an actual folder resource in GCS. Furthermore, if you want to create nested folders (eg: bucket/a/b/c/d), pass ``create_parents=True``, it will physically create all intermediate folder resources along the specified path.
 3. **No mixing or toggling:** You cannot toggle HNS on an existing flat-namespace bucket. You must create a new HNS bucket and migrate your data.
 4. **Object naming:** Object names in HNS cannot end with a slash (``/``) unless without the creation of physical folder resources.
 5. **Rename Operation Benchmarks**

docs/source/index.rst

@@ -171,7 +171,7 @@ Async
 -----
 
 ``gcsfs`` is implemented using ``aiohttp``, and offers async functionality.
-A number of methods of ``GCSFileSystem`` are ``async``, for for each of these,
+A number of methods of ``GCSFileSystem`` are ``async``, and for each of these,
 there is also a synchronous version with the same name and lack of a "_"
 prefix.
 
@@ -195,10 +195,10 @@ from normal code. If you are *not*
 using async-style programming, you do not need to know about how this
 works, but you might find the implementation interesting.
 
-For every synchronous function there is asynchronous one prefixed by ``_``, but
+For every synchronous function there is an asynchronous one prefixed by ``_``, but
 the ``open`` operation does not support async operation. If you need it to open
-some file in async manner, it's better to asynchronously download it to
-temporary location and working with it from there.
+some file in an async manner, it's better to asynchronously download it to
+a temporary location and work with it from there.
 
 Proxy
 -----

docs/source/rapid_storage_support.rst

@@ -99,14 +99,14 @@ The table below highlights how core filesystem and file-level operations change
      - Closes streams but leaves the object unfinalized (appendable) by default. Use ``finalize_on_close=True`` when opening file or calling ``close()`` or use ``.commit()`` to finalize. Note that ``autocommit`` does not work for Rapid buckets.
    * - **mv**
      - Object-level copy-and-delete logic.
-     - Uses native, atomic ``rename_folder`` API for folders. All directory semantics described in the :doc:`HNS documentation <hns_buckets>` also apply For Rapid.
+     - Uses native, atomic ``rename_folder`` API for folders. All directory semantics described in the :doc:`HNS documentation <hns_buckets>` also apply for Rapid.
 
 Performance Benchmarks
 ----------------------
 
 Rapid Storage via gRPC significantly improves read and write performance compared to standard HTTP regional buckets.
-Here are the microbenchmarks
-Rapid drastically outperform standard buckets across different read patterns, including both sequential and random reads, as well as for writes.
+Here are the microbenchmarks.
+Rapid drastically outperforms standard buckets across different read patterns, including both sequential and random reads, as well as for writes.
 To reproduce using more combinations, please see the `gcsfs/perf/microbenchmarks <https://github.com/fsspec/gcsfs/tree/main/gcsfs/tests/perf/microbenchmarks>`_ directory.
 
 .. list-table:: **Sequential Reads**
@@ -182,11 +182,11 @@ Because `gcsfs` relies on gRPC to interact with Rapid storage, developers must b
 However, gRPC Python wraps gRPC core, which uses internal multithreading for performance, and hence doesn't support `fork()`.
 Using `fork()` for multi-processing can lead to hangs or segmentation faults when child processes attempt to use the network layer
 where the application creates gRPC Python objects (e.g., client channel)before invoking `fork()`. However, if the application only
-instantiate gRPC Python objects after calling `fork()`, then `fork()` will work normally, since there is no C extension binding at this point.
+instantiates gRPC Python objects after calling `fork()`, then `fork()` will work normally, since there is no C extension binding at this point.
 
 **Alternative: Use `forkserver` or `spawn` instead of `fork`**
 
-To resolve `fork` issue, you can use `forkserver` or `spawn` instead of `fork` where the child process will create their own grpc connection.
+To resolve the `fork` issue, you can use `forkserver` or `spawn` instead of `fork` where the child processes will create their own gRPC connections.
 You can configure Python's `multiprocessing` module to override the start method as shown in the snippet below.
 For example while using data loaders in frameworks like PyTorch
 (e.g., `torch.utils.data.DataLoader` with `num_workers > 0`) alongside `gcsfs` with Rapid storage:
@@ -198,7 +198,7 @@ For example while using data loaders in frameworks like PyTorch
     # This must be done before other imports or initialization
     try:
       torch.multiprocessing.set_start_method('forkserver', force=True)
-      # or use torch.multiprocessing.set_start_method('forkserver', force=True)
+      # or use torch.multiprocessing.set_start_method('spawn', force=True)
     except RuntimeError:
       pass # Context already set