Add latest changes from gitlab-org/gitlab@13-7-stable-eev13.7.0-rc42

1 files changed, 25 insertions, 20 deletions

diff --git a/doc/administration/nfs.md b/doc/administration/nfs.md
index 3e16b173003..1e2ac531329 100644
--- a/doc/administration/nfs.md
+++ b/doc/administration/nfs.md
@@ -1,7 +1,7 @@
 ---
-stage: none
-group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+stage: Enablement
+group: Distribution
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 type: reference
 ---
 
@@ -14,7 +14,7 @@ Pages](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/196).
 For data objects such as LFS, Uploads, Artifacts, etc., an [Object Storage service](object_storage.md)
 is recommended over NFS where possible, due to better performance.
 
-CAUTION: **Caution:**
+WARNING:
 From GitLab 13.0, using NFS for Git repositories is deprecated. In GitLab 14.0,
 support for NFS for Git repositories is scheduled to be removed. Upgrade to
 [Gitaly Cluster](gitaly/praefect.md) as soon as possible.
@@ -118,7 +118,7 @@ To disable NFS server delegation, do the following:
 
 1. Restart the NFS server process. For example, on CentOS run `service nfs restart`.
 
-NOTE: **Note:**
+NOTE:
 The kernel bug may be fixed in
 [more recent kernels with this commit](https://github.com/torvalds/linux/commit/95da1b3a5aded124dd1bda1e3cdb876184813140).
 Red Hat Enterprise 7 [shipped a kernel update](https://access.redhat.com/errata/RHSA-2019:2029)
@@ -133,7 +133,7 @@ NFS performance with GitLab can in some cases be improved with
 [direct Git access](gitaly/index.md#direct-access-to-git-in-gitlab) using
 [Rugged](https://github.com/libgit2/rugged).
 
-NOTE: **Note:**
+NOTE:
 From GitLab 12.1, it will automatically be detected if Rugged can and should be used per storage.
 
 If you previously enabled Rugged using the feature flag, you will need to unset the feature flag by using:
@@ -146,7 +146,7 @@ If the Rugged feature flag is explicitly set to either `true` or `false`, GitLab
 
 #### Improving NFS performance with Puma
 
-NOTE: **Note:**
+NOTE:
 From GitLab 12.7, Rugged is not automatically enabled if Puma thread count is greater than `1`.
 
 If you want to use Rugged with Puma, [set Puma thread count to `1`](https://docs.gitlab.com/omnibus/settings/puma.html#puma-settings).
@@ -344,7 +344,7 @@ sudo ufw allow from <client_ip_address> to any port nfs
 
 ### Upgrade to Gitaly Cluster or disable caching if experiencing data loss
 
-CAUTION: **Caution:**
+WARNING:
 From GitLab 13.0, using NFS for Git repositories is deprecated. In GitLab 14.0,
 support for NFS for Git repositories is scheduled to be removed. Upgrade to
 [Gitaly Cluster](gitaly/praefect.md) as soon as possible.
@@ -358,7 +358,7 @@ For example, we have seen [inconsistent updates after a push](https://gitlab.com
 | `actimeo=0` | Sets the time to zero that the NFS client caches files and directories before requesting fresh information from a server. |
 | `noac` | Tells the NFS client not to cache file attributes and forces application writes to become synchronous so that local changes to a file become visible on the server immediately. |
 
-CAUTION: **Caution:**
+WARNING:
 The `actimeo=0` and `noac` options both result in a significant reduction in performance, possibly leading to timeouts.
 You may be able to avoid timeouts and data loss using `actimeo=0` and `lookupcache=positive` _without_ `noac`, however
 we expect the performance reduction will still be significant. As noted above, we strongly recommend upgrading to
@@ -370,7 +370,7 @@ GitLab strongly recommends against using AWS Elastic File System (EFS).
 Our support team will not be able to assist on performance issues related to
 file system access.
 
-Customers and users have reported that AWS EFS does not perform well for GitLab's
+Customers and users have reported that AWS EFS does not perform well for the GitLab
 use-case. Workloads where many small files are written in a serialized manner, like `git`,
 are not well-suited for EFS. EBS with an NFS server on top will perform much better.
 
@@ -383,7 +383,7 @@ For more details on another person's experience with EFS, see this [Commit Brook
 ### Avoid using CephFS and GlusterFS
 
 GitLab strongly recommends against using CephFS and GlusterFS.
-These distributed file systems are not well-suited for GitLab's input/output access patterns because Git uses many small files and access times and file locking times to propagate will make Git activity very slow.
+These distributed file systems are not well-suited for the GitLab input/output access patterns because Git uses many small files and access times and file locking times to propagate will make Git activity very slow.
 
 ### Avoid using PostgreSQL with NFS
 
@@ -402,14 +402,19 @@ Additionally, this configuration is specifically warned against in the
 For supported database architecture, see our documentation about
 [configuring a database for replication and failover](postgresql/replication_and_failover.md).
 
-<!-- ## Troubleshooting
+## Troubleshooting
 
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-questions that you know someone might ask.
+### Finding the requests that are being made to NFS
 
-Each scenario can be a third-level heading, e.g. `### Getting error message X`.
-If you have none to add when creating a doc, leave this section in place
-but commented out to help encourage others to add to it in the future. -->
+In case of NFS-related problems, it can be helpful to trace
+the filesystem requests that are being made by using `perf`:
+
+```shell
+sudo perf trace -e 'nfs4:*' -p $(pgrep -fd ',' puma && pgrep -fd ',' unicorn)
+```
+
+On Ubuntu 16.04, use:
+
+```shell
+sudo perf trace --no-syscalls --event 'nfs4:*' -p $(pgrep -fd ',' puma && pgrep -fd ',' unicorn)
+```