요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
Reexporting NFS filesystems
===========================
Overview
--------
It is possible to reexport an NFS filesystem over NFS. However, this
feature comes with a number of limitations. Before trying it, we
recommend some careful research to determine whether it will work for
your purposes.
A discussion of current known limitations follows.
"fsid=" required, crossmnt broken
---------------------------------
We require the "fsid=" export option on any reexport of an NFS
filesystem. You can use "uuidgen -r" to generate a unique argument.
The "crossmnt" export does not propagate "fsid=", so it will not allow
traversing into further nfs filesystems; if you wish to export nfs
filesystems mounted under the exported filesystem, you'll need to export
them explicitly, assigning each its own unique "fsid= option.
Reboot recovery
---------------
The NFS protocol's normal reboot recovery mechanisms don't work for the
case when the reexport server reboots because the source server has not
rebooted, and so it is not in grace. Since the source server is not in
grace, it cannot offer any guarantees that the file won't have been
changed between the locks getting lost and any attempt to recover them.
The same applies to delegations and any associated locks. Clients are
not allowed to get file locks or delegations from a reexport server, any
attempts will fail with operation not supported.
Filehandle limits
-----------------
If the original server uses an X byte filehandle for a given object, the
reexport server's filehandle for the reexported object will be X+22
bytes, rounded up to the nearest multiple of four bytes.
The result must fit into the RFC-mandated filehandle size limits:
+-------+-----------+
| NFSv2 | 32 bytes |
+-------+-----------+
| NFSv3 | 64 bytes |
+-------+-----------+
| NFSv4 | 128 bytes |
+-------+-----------+
So, for example, you will only be able to reexport a filesystem over
NFSv2 if the original server gives you filehandles that fit in 10
bytes--which is unlikely.
In general there's no way to know the maximum filehandle size given out
by an NFS server without asking the server vendor.
But the following table gives a few examples. The first column is the
typical length of the filehandle from a Linux server exporting the given
filesystem, the second is the length after that nfs export is reexported
by another Linux host:
+--------+-------------------+----------------+
| | filehandle length | after reexport |
+========+===================+================+
| ext4: | 28 bytes | 52 bytes |
+--------+-------------------+----------------+
| xfs: | 32 bytes | 56 bytes |
+--------+-------------------+----------------+
| btrfs: | 40 bytes | 64 bytes |
+--------+-------------------+----------------+
All will therefore fit in an NFSv3 or NFSv4 filehandle after reexport,
but none are reexportable over NFSv2.
Linux server filehandles are a bit more complicated than this, though;
for example:
- The (non-default) "subtreecheck" export option generally
requires another 4 to 8 bytes in the filehandle.
- If you export a subdirectory of a filesystem (instead of
exporting the filesystem root), that also usually adds 4 to 8
bytes.
- If you export over NFSv2, knfsd usually uses a shorter
filesystem identifier that saves 8 bytes.
- The root directory of an export uses a filehandle that is
shorter.
As you can see, the 128-byte NFSv4 filehandle is large enough that
you're unlikely to have trouble using NFSv4 to reexport any filesystem
exported from a Linux server. In general, if the original server is
something that also supports NFSv3, you're *probably* OK. Re-exporting
over NFSv3 may be dicier, and reexporting over NFSv2 will probably
never work.
For more details of Linux filehandle structure, the best reference is
the source code and comments; see in particular:
- include/linux/exportfs.h:enum fid_type
- include/uapi/linux/nfsd/nfsfh.h:struct nfs_fhbase_new
- fs/nfsd/nfsfh.c:set_version_and_fsid_type
- fs/nfs/export.c:nfs_encode_fh
Open DENY bits ignored
----------------------
NFS since NFSv4 supports ALLOW and DENY bits taken from Windows, which
allow you, for example, to open a file in a mode which forbids other
read opens or write opens. The Linux client doesn't use them, and the
server's support has always been incomplete: they are enforced only
against other NFS users, not against processes accessing the exported
filesystem locally. A reexport server will also not pass them along to
the original server, so they will not be enforced between clients of
different reexport servers.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
NFS reexport의 범위와 주의
1-13NFS로 mount한 filesystem을 다시 NFS로 export하는 reexport는 가능합니다. 다만 알려진 제한이 여러 가지이므로 실제 적용 전에 목적과 workload에 맞게 동작하는지 충분히 조사해야 합니다.
이어지는 절은 unique `fsid`, reboot recovery, filehandle 길이, NFSv4 open DENY bit 전달과 관련된 현재 제한을 설명합니다.
Original server와 최종 client 사이에 reexport server가 들어갑니다.
Reexporting NFS filesystems
===========================
Overview
--------
It is possible to reexport an NFS filesystem over NFS. However, this
feature comes with a number of limitations. Before trying it, we
recommend some careful research to determine whether it will work for
your purposes.
A discussion of current known limitations follows.
필수 fsid와 crossmnt 제한
14-24NFS filesystem을 reexport하는 모든 export에는 `fsid=` option이 필수입니다. 고유한 argument는 `uuidgen -r`로 생성할 수 있습니다.
`crossmnt` export는 `fsid=`를 하위 mount로 전달하지 않으므로 그 아래에 mount된 추가 NFS filesystem으로 traversal할 수 없습니다.
Export한 filesystem 아래에 mount된 NFS filesystem까지 제공하려면 각 하위 filesystem을 명시적으로 export하고 저마다 고유한 `fsid=`를 부여해야 합니다.
상위 export와 하위 NFS mount를 별도 identity로 취급합니다.
"fsid=" required, crossmnt broken
---------------------------------
We require the "fsid=" export option on any reexport of an NFS
filesystem. You can use "uuidgen -r" to generate a unique argument.
The "crossmnt" export does not propagate "fsid=", so it will not allow
traversing into further nfs filesystems; if you wish to export nfs
filesystems mounted under the exported filesystem, you'll need to export
them explicitly, assigning each its own unique "fsid= option.
Reexport server reboot와 state recovery 제한
25-36Reexport server가 reboot한 경우에는 NFS protocol의 일반 reboot recovery가 동작하지 않습니다. Source server는 reboot하지 않았으므로 grace period에 들어가지 않기 때문입니다.
Source server가 grace 상태가 아니면 lock을 잃은 시점과 recovery 시도 사이에 file이 변경되지 않았다고 보장할 수 없습니다. Delegation과 그에 연결된 lock에도 같은 문제가 적용됩니다.
따라서 client는 reexport server에서 file lock이나 delegation을 받을 수 없습니다. 이를 요청하면 `operation not supported`로 실패합니다.
중간 server만 reboot할 때 source server의 grace가 시작되지 않습니다.
Reboot recovery
---------------
The NFS protocol's normal reboot recovery mechanisms don't work for the
case when the reexport server reboots because the source server has not
rebooted, and so it is not in grace. Since the source server is not in
grace, it cannot offer any guarantees that the file won't have been
changed between the locks getting lost and any attempt to recover them.
The same applies to delegations and any associated locks. Clients are
not allowed to get file locks or delegations from a reexport server, any
attempts will fail with operation not supported.
Filehandle 증가식과 protocol 한도
37-60Original server가 어떤 object에 X byte filehandle을 사용하면 reexport server가 만드는 filehandle은 X+22 byte가 되고, 그 값을 4-byte 배수로 올림합니다.
결과는 RFC가 정한 NFS version별 최대 filehandle 크기 안에 들어야 합니다. NFSv2는 32 byte, NFSv3는 64 byte, NFSv4는 128 byte입니다.
예를 들어 NFSv2로 reexport하려면 original filehandle이 10 byte 안에 들어야 하므로 현실적으로 성공하기 어렵습니다. 일반적으로 NFS server가 내놓는 최대 filehandle 크기는 vendor에 문의하지 않고는 알 수 없습니다.
Reexport 결과는 `ceil4(X + 22)`이며 version 한도를 넘을 수 없습니다.
Filehandle limits
-----------------
If the original server uses an X byte filehandle for a given object, the
reexport server's filehandle for the reexported object will be X+22
bytes, rounded up to the nearest multiple of four bytes.
The result must fit into the RFC-mandated filehandle size limits:
+-------+-----------+
| NFSv2 | 32 bytes |
+-------+-----------+
| NFSv3 | 64 bytes |
+-------+-----------+
| NFSv4 | 128 bytes |
+-------+-----------+
So, for example, you will only be able to reexport a filesystem over
NFSv2 if the original server gives you filehandles that fit in 10
bytes--which is unlikely.
In general there's no way to know the maximum filehandle size given out
by an NFS server without asking the server vendor.
Linux filesystem별 filehandle 예와 변동 요인
61-106Linux server의 일반적인 filehandle 길이 예에서 ext4는 28 byte가 reexport 뒤 52 byte, XFS는 32 byte가 56 byte, Btrfs는 40 byte가 64 byte가 됩니다. 모두 NFSv3와 NFSv4 한도에는 들어가지만 NFSv2로는 reexport할 수 없습니다.
실제 Linux server filehandle은 option과 export 위치에 따라 달라집니다. 기본값이 아닌 `subtreecheck`는 보통 4~8 byte를 더 요구하고, filesystem root가 아니라 subdirectory를 export해도 대개 4~8 byte가 추가됩니다.
NFSv2로 export할 때 knfsd는 보통 8 byte를 절약하는 더 짧은 filesystem identifier를 사용합니다. Export root directory의 filehandle도 더 짧습니다.
128-byte NFSv4 filehandle은 충분히 커서 Linux server가 export한 filesystem을 NFSv4로 reexport할 때 문제를 겪을 가능성이 낮습니다. Original server가 NFSv3도 지원한다면 대체로 괜찮을 가능성이 있지만 NFSv3 reexport는 더 불확실하고 NFSv2는 거의 동작하지 않을 가능성이 큽니다.
Linux filehandle 구조의 상세 기준은 source와 comment입니다. 관련 symbol은 `include/linux/exportfs.h:enum fid_type`, `include/uapi/linux/nfsd/nfsfh.h:struct nfs_fhbase_new`, `fs/nfsd/nfsfh.c:set_version_and_fsid_type`, `fs/nfs/export.c:nfs_encode_fh`입니다.
원문에 제시된 일반적인 길이이며 option에 따라 달라질 수 있습니다.
But the following table gives a few examples. The first column is the
typical length of the filehandle from a Linux server exporting the given
filesystem, the second is the length after that nfs export is reexported
by another Linux host:
+--------+-------------------+----------------+
| | filehandle length | after reexport |
+========+===================+================+
| ext4: | 28 bytes | 52 bytes |
+--------+-------------------+----------------+
| xfs: | 32 bytes | 56 bytes |
+--------+-------------------+----------------+
| btrfs: | 40 bytes | 64 bytes |
+--------+-------------------+----------------+
All will therefore fit in an NFSv3 or NFSv4 filehandle after reexport,
but none are reexportable over NFSv2.
Linux server filehandles are a bit more complicated than this, though;
for example:
- The (non-default) "subtreecheck" export option generally
requires another 4 to 8 bytes in the filehandle.
- If you export a subdirectory of a filesystem (instead of
exporting the filesystem root), that also usually adds 4 to 8
bytes.
- If you export over NFSv2, knfsd usually uses a shorter
filesystem identifier that saves 8 bytes.
- The root directory of an export uses a filehandle that is
shorter.
As you can see, the 128-byte NFSv4 filehandle is large enough that
you're unlikely to have trouble using NFSv4 to reexport any filesystem
exported from a Linux server. In general, if the original server is
something that also supports NFSv3, you're *probably* OK. Re-exporting
over NFSv3 may be dicier, and reexporting over NFSv2 will probably
never work.
For more details of Linux filehandle structure, the best reference is
the source code and comments; see in particular:
- include/linux/exportfs.h:enum fid_type
- include/uapi/linux/nfsd/nfsfh.h:struct nfs_fhbase_new
- fs/nfsd/nfsfh.c:set_version_and_fsid_type
- fs/nfs/export.c:nfs_encode_fh
NFSv4 open DENY bit가 전달되지 않는 범위
107-117NFSv4부터 Windows에서 가져온 open `ALLOW`와 `DENY` bit를 지원합니다. 예를 들어 다른 read open이나 write open을 금지하는 mode로 file을 열 수 있습니다.
Linux NFS client는 이 bit를 사용하지 않으며 server 지원도 완전하지 않습니다. DENY는 다른 NFS user에 대해서만 enforce되고 exported filesystem을 local process가 접근하는 경우에는 적용되지 않습니다.
Reexport server는 DENY bit를 original server로 전달하지 않습니다. 따라서 서로 다른 reexport server에 연결된 client 사이에서는 이 제한이 enforce되지 않습니다.
Reexport hop과 local access에서 sharing restriction이 끊깁니다.
Open DENY bits ignored
----------------------
NFS since NFSv4 supports ALLOW and DENY bits taken from Windows, which
allow you, for example, to open a file in a mode which forbids other
read opens or write opens. The Linux client doesn't use them, and the
server's support has always been incomplete: they are enforced only
against other NFS users, not against processes accessing the exported
filesystem locally. A reexport server will also not pass them along to
the original server, so they will not be enforced between clients of
different reexport servers.
요약·해설
reexport.rst:1-117NFS reexport에는 각 filesystem별 고유 `fsid=`가 필요하고 `crossmnt`가 이를 하위 NFS mount로 전파하지 않습니다. 중간 server만 reboot하면 source server에 grace가 없어 lock·delegation recovery를 보장할 수 없습니다.
Reexport filehandle은 original 길이에 22 byte를 더해 4-byte 배수로 올림하므로 NFS version 한도를 확인해야 합니다. NFSv4는 대체로 여유가 있지만 NFSv2는 거의 불가능하며, open DENY bit도 reexport 경계를 넘어 전달되지 않습니다.
구성 전에 확인할 네 가지 제한입니다.