NFS re-export
From Linux NFS
| Line 3: | Line 3: | ||
Some known issues: | Some known issues: | ||
| - | = fsid= required | + | = fsid= required = |
The "fsid=" option is required on any export of an NFS filesystem. | The "fsid=" option is required on any export of an NFS filesystem. | ||
| - | = filehandle limits | + | = filehandle limits = |
NFS filehandle sizes are limited (to 32 bytes for NFSv2, 64 bytes for NFSv3, and 128 bytes for NFSv4). When we re-export, we take the filehandle returned from the original server and wrap it with some more bytes of our own to create the filehandle we return to clients. That means the filehandles we give out will be larger than the filehandles we receive from the original server. There's no guarantee this will work. In practice most servers give out filehandles of a fixed size that's less than the maximum, so you *probably* won't run into this problem unless you're re-exporting with NFSv2, or re-exporting repeatedly. But there are no guarantees. | NFS filehandle sizes are limited (to 32 bytes for NFSv2, 64 bytes for NFSv3, and 128 bytes for NFSv4). When we re-export, we take the filehandle returned from the original server and wrap it with some more bytes of our own to create the filehandle we return to clients. That means the filehandles we give out will be larger than the filehandles we receive from the original server. There's no guarantee this will work. In practice most servers give out filehandles of a fixed size that's less than the maximum, so you *probably* won't run into this problem unless you're re-exporting with NFSv2, or re-exporting repeatedly. But there are no guarantees. | ||
| - | = unnecessary GETATTRs | + | = unnecessary GETATTRs = |
We see unnecessary cache invalidations on the re-export servers; we have some patches in progress that should make it for 5.11 or so (https://lore.kernel.org/linux-nfs/20201120223831.GB7705@fieldses.org/). It looks like they help but don't address every case. | We see unnecessary cache invalidations on the re-export servers; we have some patches in progress that should make it for 5.11 or so (https://lore.kernel.org/linux-nfs/20201120223831.GB7705@fieldses.org/). It looks like they help but don't address every case. | ||
| - | = Incorrect pre/post-operation attributes | + | = Incorrect pre/post-operation attributes = |
Pre/post-operation attributes are incorrectly returned as if they were atomic in cases when they aren't. This could cause clients to incorrectly cache stale file data or directory contents. This is fixable but we don't currently have patches. | Pre/post-operation attributes are incorrectly returned as if they were atomic in cases when they aren't. This could cause clients to incorrectly cache stale file data or directory contents. This is fixable but we don't currently have patches. | ||
| - | = locking crash | + | = locking crash = |
Connectathon locking tests are currently triggering some kind of memory corruption; still investigating. | Connectathon locking tests are currently triggering some kind of memory corruption; still investigating. | ||
| - | = Known problems that we've fixed | + | = Known problems that we've fixed = |
* Problems with sporadic stale filehandles should be fixed by https://lore.kernel.org/linux-nfs/20201019175330.595894-1-trondmy@kernel.org/ (queued for 5.11?) | * Problems with sporadic stale filehandles should be fixed by https://lore.kernel.org/linux-nfs/20201019175330.595894-1-trondmy@kernel.org/ (queued for 5.11?) | ||
Revision as of 18:29, 25 November 2020
The Linux NFS server can export an NFS mount, but that isn't something we currently recommend unless you've done some careful research and are prepared for problems.
Some known issues:
Contents |
fsid= required
The "fsid=" option is required on any export of an NFS filesystem.
filehandle limits
NFS filehandle sizes are limited (to 32 bytes for NFSv2, 64 bytes for NFSv3, and 128 bytes for NFSv4). When we re-export, we take the filehandle returned from the original server and wrap it with some more bytes of our own to create the filehandle we return to clients. That means the filehandles we give out will be larger than the filehandles we receive from the original server. There's no guarantee this will work. In practice most servers give out filehandles of a fixed size that's less than the maximum, so you *probably* won't run into this problem unless you're re-exporting with NFSv2, or re-exporting repeatedly. But there are no guarantees.
unnecessary GETATTRs
We see unnecessary cache invalidations on the re-export servers; we have some patches in progress that should make it for 5.11 or so (https://lore.kernel.org/linux-nfs/20201120223831.GB7705@fieldses.org/). It looks like they help but don't address every case.
Incorrect pre/post-operation attributes
Pre/post-operation attributes are incorrectly returned as if they were atomic in cases when they aren't. This could cause clients to incorrectly cache stale file data or directory contents. This is fixable but we don't currently have patches.
locking crash
Connectathon locking tests are currently triggering some kind of memory corruption; still investigating.
Known problems that we've fixed
- Problems with sporadic stale filehandles should be fixed by https://lore.kernel.org/linux-nfs/20201019175330.595894-1-trondmy@kernel.org/ (queued for 5.11?)
