요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
==========================
Reference counting in pnfs
==========================
The are several inter-related caches. We have layouts which can
reference multiple devices, each of which can reference multiple data servers.
Each data server can be referenced by multiple devices. Each device
can be referenced by multiple layouts. To keep all of this straight,
we need to reference count.
struct pnfs_layout_hdr
======================
The on-the-wire command LAYOUTGET corresponds to struct
pnfs_layout_segment, usually referred to by the variable name lseg.
Each nfs_inode may hold a pointer to a cache of these layout
segments in nfsi->layout, of type struct pnfs_layout_hdr.
We reference the header for the inode pointing to it, across each
outstanding RPC call that references it (LAYOUTGET, LAYOUTRETURN,
LAYOUTCOMMIT), and for each lseg held within.
Each header is also (when non-empty) put on a list associated with
struct nfs_client (cl_layouts). Being put on this list does not bump
the reference count, as the layout is kept around by the lseg that
keeps it in the list.
deviceid_cache
==============
lsegs reference device ids, which are resolved per nfs_client and
layout driver type. The device ids are held in a RCU cache (struct
nfs4_deviceid_cache). The cache itself is referenced across each
mount. The entries (struct nfs4_deviceid) themselves are held across
the lifetime of each lseg referencing them.
RCU is used because the deviceid is basically a write once, read many
data structure. The hlist size of 32 buckets needs better
justification, but seems reasonable given that we can have multiple
deviceid's per filesystem, and multiple filesystems per nfs_client.
The hash code is copied from the nfsd code base. A discussion of
hashing and variations of this algorithm can be found `here.
<http://groups.google.com/group/comp.lang.c/browse_thread/thread/9522965e2b8d3809>`_
data server cache
=================
file driver devices refer to data servers, which are kept in a module
level cache. Its reference is held over the lifetime of the deviceid
pointing to it.
lseg
====
lseg maintains an extra reference corresponding to the NFS_LSEG_VALID
bit which holds it in the pnfs_layout_hdr's list. When the final lseg
is removed from the pnfs_layout_hdr's list, the NFS_LAYOUT_DESTROYED
bit is set, preventing any new lsegs from being added.
layout drivers
==============
PNFS utilizes what is called layout drivers. The STD defines 4 basic
layout types: "files", "objects", "blocks", and "flexfiles". For each
of these types there is a layout-driver with a common function-vectors
table which are called by the nfs-client pnfs-core to implement the
different layout types.
Files-layout-driver code is in: fs/nfs/filelayout/.. directory
Blocks-layout-driver code is in: fs/nfs/blocklayout/.. directory
Flexfiles-layout-driver code is in: fs/nfs/flexfilelayout/.. directory
blocks-layout setup
===================
TODO: Document the setup needs of the blocks layout driver
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
pNFS cache 사이의 reference graph
1-10pNFS에는 서로 연결된 cache가 여러 개 있습니다. Layout 하나는 여러 device를 참조할 수 있고, device 하나는 여러 data server를 참조할 수 있습니다.
반대 방향의 공유도 존재합니다. Data server 하나를 여러 device가 참조할 수 있고, device 하나를 여러 layout이 참조할 수 있습니다. 이 many-to-many 관계에서 object를 너무 일찍 해제하거나 누수하지 않으려면 모든 연결에 reference counting이 필요합니다.
Layout, device와 data server 사이의 다중 참조 구조입니다.
==========================
Reference counting in pnfs
==========================
The are several inter-related caches. We have layouts which can
reference multiple devices, each of which can reference multiple data servers.
Each data server can be referenced by multiple devices. Each device
can be referenced by multiple layouts. To keep all of this straight,
we need to reference count.
struct pnfs_layout_hdr의 참조 수명
11-28Wire protocol의 `LAYOUTGET` command는 `struct pnfs_layout_segment`에 대응하며 변수 이름으로는 보통 `lseg`라고 부릅니다. 각 `nfs_inode`는 `nfsi->layout`에 layout segment cache pointer를 가질 수 있고 그 type은 `struct pnfs_layout_hdr`입니다.
Layout header의 reference는 이를 가리키는 inode 하나, 해당 header를 참조하는 outstanding RPC call 각각, header 안에 보관된 lseg 각각에 대해 유지합니다. 관련 RPC는 `LAYOUTGET`, `LAYOUTRETURN`, `LAYOUTCOMMIT`입니다.
비어 있지 않은 header는 `struct nfs_client`의 `cl_layouts` list에도 들어갑니다. 그러나 list membership 자체는 reference count를 올리지 않습니다. Header를 list에 남겨 두는 lseg가 이미 그 수명을 보장하기 때문입니다.
Header를 살아 있게 하는 실제 reference와 비소유 list를 구분합니다.
struct pnfs_layout_hdr
======================
The on-the-wire command LAYOUTGET corresponds to struct
pnfs_layout_segment, usually referred to by the variable name lseg.
Each nfs_inode may hold a pointer to a cache of these layout
segments in nfsi->layout, of type struct pnfs_layout_hdr.
We reference the header for the inode pointing to it, across each
outstanding RPC call that references it (LAYOUTGET, LAYOUTRETURN,
LAYOUTCOMMIT), and for each lseg held within.
Each header is also (when non-empty) put on a list associated with
struct nfs_client (cl_layouts). Being put on this list does not bump
the reference count, as the layout is kept around by the lseg that
keeps it in the list.
nfs4_deviceid_cache와 RCU
29-46Lseg는 device ID를 참조하며, 이 ID는 `nfs_client`와 layout-driver type별로 resolve됩니다. Device ID는 RCU cache인 `struct nfs4_deviceid_cache`에 저장됩니다.
Cache 자체의 reference는 각 mount 수명 동안 유지하고, cache entry인 `struct nfs4_deviceid`의 reference는 그 entry를 참조하는 각 lseg의 수명 동안 유지합니다.
Device ID는 기본적으로 한 번 쓰고 여러 번 읽는 data structure이므로 RCU를 사용합니다. Hlist는 32 bucket이며 더 엄밀한 근거가 필요하지만, filesystem마다 device ID가 여러 개이고 `nfs_client`마다 filesystem이 여러 개일 수 있다는 점에서 합리적인 크기로 봅니다.
Hash code는 nfsd code base에서 가져왔으며 원문은 hashing과 이 algorithm 변형을 논의한 외부 링크를 제공합니다.
Cache와 entry의 reference owner가 서로 다릅니다.
deviceid_cache
==============
lsegs reference device ids, which are resolved per nfs_client and
layout driver type. The device ids are held in a RCU cache (struct
nfs4_deviceid_cache). The cache itself is referenced across each
mount. The entries (struct nfs4_deviceid) themselves are held across
the lifetime of each lseg referencing them.
RCU is used because the deviceid is basically a write once, read many
data structure. The hlist size of 32 buckets needs better
justification, but seems reasonable given that we can have multiple
deviceid's per filesystem, and multiple filesystems per nfs_client.
The hash code is copied from the nfsd code base. A discussion of
hashing and variations of this algorithm can be found `here.
<http://groups.google.com/group/comp.lang.c/browse_thread/thread/9522965e2b8d3809>`_
Data server cache와 lseg invalidation
47-61File layout driver의 device는 data server를 참조합니다. Data server는 module-level cache에 보관되며, 이를 가리키는 device ID의 전체 수명 동안 reference가 유지됩니다.
Lseg는 `NFS_LSEG_VALID` bit에 대응하는 추가 reference를 유지합니다. 이 reference가 lseg를 `pnfs_layout_hdr`의 list 안에 남겨 둡니다.
마지막 lseg가 `pnfs_layout_hdr` list에서 제거되면 `NFS_LAYOUT_DESTROYED` bit를 설정합니다. 이 bit는 이미 파괴 단계에 들어간 header에 새 lseg가 추가되는 것을 막아 list와 object lifetime을 일관되게 유지합니다.
VALID reference가 사라진 뒤 layout header를 닫는 순서입니다.
data server cache
=================
file driver devices refer to data servers, which are kept in a module
level cache. Its reference is held over the lifetime of the deviceid
pointing to it.
lseg
====
lseg maintains an extra reference corresponding to the NFS_LSEG_VALID
bit which holds it in the pnfs_layout_hdr's list. When the final lseg
is removed from the pnfs_layout_hdr's list, the NFS_LAYOUT_DESTROYED
bit is set, preventing any new lsegs from being added.
Layout driver type과 source path
62-78pNFS는 layout driver라는 abstraction을 사용합니다. 표준은 `files`, `objects`, `blocks`, `flexfiles`의 네 기본 layout type을 정의합니다.
각 type에는 공통 function-vector table을 구현하는 layout driver가 있으며, NFS client의 pNFS core가 이 vector를 호출해 서로 다른 layout type의 동작을 수행합니다.
Files layout driver source는 `fs/nfs/filelayout/..`, blocks layout driver는 `fs/nfs/blocklayout/..`, flexfiles layout driver는 `fs/nfs/flexfilelayout/..`에 있습니다. 원문에는 objects layout의 source path가 별도로 제시되지 않습니다.
마지막 `blocks-layout setup` 절은 blocks layout driver의 setup 요구 사항을 문서화해야 한다는 미작성 표지만 있습니다. 현재 원문에 실제 setup 절차가 없으므로 번역도 이를 완료된 절차처럼 보충하지 않습니다.
표준 type과 원문에 명시된 Linux source path입니다.
layout drivers
==============
PNFS utilizes what is called layout drivers. The STD defines 4 basic
layout types: "files", "objects", "blocks", and "flexfiles". For each
of these types there is a layout-driver with a common function-vectors
table which are called by the nfs-client pnfs-core to implement the
different layout types.
Files-layout-driver code is in: fs/nfs/filelayout/.. directory
Blocks-layout-driver code is in: fs/nfs/blocklayout/.. directory
Flexfiles-layout-driver code is in: fs/nfs/flexfilelayout/.. directory
blocks-layout setup
===================
TODO: Document the setup needs of the blocks layout driver
요약·해설
pnfs.rst:1-78pNFS는 layout, device ID, data server가 many-to-many로 연결되므로 inode, outstanding layout RPC, lseg, mount와 device 수명에 맞춰 reference를 나눠 관리합니다. RCU는 write-once/read-many device ID cache의 빠른 lookup을 지원합니다.
마지막 valid lseg가 제거되면 `NFS_LAYOUT_DESTROYED`로 새 segment 추가를 막습니다. Layout type은 files, objects, blocks, flexfiles이며 blocks-layout setup의 구체 절차는 원문에도 아직 없습니다.
상위 layout에서 data server까지 reference owner를 연결합니다.