Document why not to use GlusterFS and CephFS for storage
Per the conversation here, we need to cover in docs that Gluster and Ceph FS will not work for GitLab. Similar issues as EFS. These are not recommended or supported.
Proposal
-
We can simply rename and expand this EFS section to cover all three, and if there are substantial differences among the systems to cover, give each one a subsection:
https://docs.gitlab.com/ee/administration/high_availability/nfs.html#avoid-using-awss-elastic-file-system-efs -
We can mention points from this post, specifically, the first paragraph of the "Network and I/O latency" section
-
We can convey the points in Stan's comment:
When you write files on replicated servers, the client has to roll through the same process first. Once that’s done, it has to lock the file, write to the change log, then do the write operation, drop the change log entries, and then unlock the file. All of those operations must be done on all of the servers. High latency networks will wreak havoc on this process and cause it to take longer than it should.
- While here, we can drop the link to the third party EFS Burst Credits blog post and replace it with a sentence or two TL;DR; something like "if EFS is used, note that GitLab may quickly consume your Burst Credits".
Who can address the issue
Support or other participant in the original thread.