요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
==========
MD Cluster
==========
The cluster MD is a shared-device RAID for a cluster, it supports
two levels: raid1 and raid10 (limited support).
1. On-disk format
=================
Separate write-intent-bitmaps are used for each cluster node.
The bitmaps record all writes that may have been started on that node,
and may not yet have finished. The on-disk layout is::
0 4k 8k 12k
-------------------------------------------------------------------
| idle | md super | bm super [0] + bits |
| bm bits[0, contd] | bm super[1] + bits | bm bits[1, contd] |
| bm super[2] + bits | bm bits [2, contd] | bm super[3] + bits |
| bm bits [3, contd] | | |
During "normal" functioning we assume the filesystem ensures that only
one node writes to any given block at a time, so a write request will
- set the appropriate bit (if not already set)
- commit the write to all mirrors
- schedule the bit to be cleared after a timeout.
Reads are just handled normally. It is up to the filesystem to ensure
one node doesn't read from a location where another node (or the same
node) is writing.
2. DLM Locks for management
===========================
There are three groups of locks for managing the device:
2.1 Bitmap lock resource (bm_lockres)
-------------------------------------
The bm_lockres protects individual node bitmaps. They are named in
the form bitmap000 for node 1, bitmap001 for node 2 and so on. When a
node joins the cluster, it acquires the lock in PW mode and it stays
so during the lifetime the node is part of the cluster. The lock
resource number is based on the slot number returned by the DLM
subsystem. Since DLM starts node count from one and bitmap slots
start from zero, one is subtracted from the DLM slot number to arrive
at the bitmap slot number.
The LVB of the bitmap lock for a particular node records the range
of sectors that are being re-synced by that node. No other
node may write to those sectors. This is used when a new nodes
joins the cluster.
2.2 Message passing locks
-------------------------
Each node has to communicate with other nodes when starting or ending
resync, and for metadata superblock updates. This communication is
managed through three locks: "token", "message", and "ack", together
with the Lock Value Block (LVB) of one of the "message" lock.
2.3 new-device management
-------------------------
A single lock: "no-new-dev" is used to coordinate the addition of
new devices - this must be synchronized across the array.
Normally all nodes hold a concurrent-read lock on this device.
3. Communication
================
Messages can be broadcast to all nodes, and the sender waits for all
other nodes to acknowledge the message before proceeding. Only one
message can be processed at a time.
3.1 Message Types
-----------------
There are six types of messages which are passed:
3.1.1 METADATA_UPDATED
^^^^^^^^^^^^^^^^^^^^^^
informs other nodes that the metadata has
been updated, and the node must re-read the md superblock. This is
performed synchronously. It is primarily used to signal device
failure.
3.1.2 RESYNCING
^^^^^^^^^^^^^^^
informs other nodes that a resync is initiated or
ended so that each node may suspend or resume the region. Each
RESYNCING message identifies a range of the devices that the
sending node is about to resync. This overrides any previous
notification from that node: only one ranged can be resynced at a
time per-node.
3.1.3 NEWDISK
^^^^^^^^^^^^^
informs other nodes that a device is being added to
the array. Message contains an identifier for that device. See
below for further details.
3.1.4 REMOVE
^^^^^^^^^^^^
A failed or spare device is being removed from the
array. The slot-number of the device is included in the message.
3.1.5 RE_ADD:
A failed device is being re-activated - the assumption
is that it has been determined to be working again.
3.1.6 BITMAP_NEEDS_SYNC:
If a node is stopped locally but the bitmap
isn't clean, then another node is informed to take the ownership of
resync.
3.2 Communication mechanism
---------------------------
The DLM LVB is used to communicate within nodes of the cluster. There
are three resources used for the purpose:
3.2.1 token
^^^^^^^^^^^
The resource which protects the entire communication
system. The node having the token resource is allowed to
communicate.
3.2.2 message
^^^^^^^^^^^^^
The lock resource which carries the data to communicate.
3.2.3 ack
^^^^^^^^^
The resource, acquiring which means the message has been
acknowledged by all nodes in the cluster. The BAST of the resource
is used to inform the receiving node that a node wants to
communicate.
The algorithm is:
1. receive status - all nodes have concurrent-reader lock on "ack"::
sender receiver receiver
"ack":CR "ack":CR "ack":CR
2. sender get EX on "token",
sender get EX on "message"::
sender receiver receiver
"token":EX "ack":CR "ack":CR
"message":EX
"ack":CR
Sender checks that it still needs to send a message. Messages
received or other events that happened while waiting for the
"token" may have made this message inappropriate or redundant.
3. sender writes LVB
sender down-convert "message" from EX to CW
sender try to get EX of "ack"
::
[ wait until all receivers have *processed* the "message" ]
[ triggered by bast of "ack" ]
receiver get CR on "message"
receiver read LVB
receiver processes the message
[ wait finish ]
receiver releases "ack"
receiver tries to get PR on "message"
sender receiver receiver
"token":EX "message":CR "message":CR
"message":CW
"ack":EX
4. triggered by grant of EX on "ack" (indicating all receivers
have processed message)
sender down-converts "ack" from EX to CR
sender releases "message"
sender releases "token"
::
receiver upconvert to PR on "message"
receiver get CR of "ack"
receiver release "message"
sender receiver receiver
"ack":CR "ack":CR "ack":CR
4. Handling Failures
====================
4.1 Node Failure
----------------
When a node fails, the DLM informs the cluster with the slot
number. The node starts a cluster recovery thread. The cluster
recovery thread:
- acquires the bitmap<number> lock of the failed node
- opens the bitmap
- reads the bitmap of the failed node
- copies the set bitmap to local node
- cleans the bitmap of the failed node
- releases bitmap<number> lock of the failed node
- initiates resync of the bitmap on the current node
md_check_recovery is invoked within recover_bitmaps,
then md_check_recovery -> metadata_update_start/finish,
it will lock the communication by lock_comm.
Which means when one node is resyncing it blocks all
other nodes from writing anywhere on the array.
The resync process is the regular md resync. However, in a clustered
environment when a resync is performed, it needs to tell other nodes
of the areas which are suspended. Before a resync starts, the node
send out RESYNCING with the (lo,hi) range of the area which needs to
be suspended. Each node maintains a suspend_list, which contains the
list of ranges which are currently suspended. On receiving RESYNCING,
the node adds the range to the suspend_list. Similarly, when the node
performing resync finishes, it sends RESYNCING with an empty range to
other nodes and other nodes remove the corresponding entry from the
suspend_list.
A helper function, ->area_resyncing() can be used to check if a
particular I/O range should be suspended or not.
4.2 Device Failure
==================
Device failures are handled and communicated with the metadata update
routine. When a node detects a device failure it does not allow
any further writes to that device until the failure has been
acknowledged by all other nodes.
5. Adding a new Device
----------------------
For adding a new device, it is necessary that all nodes "see" the new
device to be added. For this, the following algorithm is used:
1. Node 1 issues mdadm --manage /dev/mdX --add /dev/sdYY which issues
ioctl(ADD_NEW_DISK with disc.state set to MD_DISK_CLUSTER_ADD)
2. Node 1 sends a NEWDISK message with uuid and slot number
3. Other nodes issue kobject_uevent_env with uuid and slot number
(Steps 4,5 could be a udev rule)
4. In userspace, the node searches for the disk, perhaps
using blkid -t SUB_UUID=""
5. Other nodes issue either of the following depending on whether
the disk was found:
ioctl(ADD_NEW_DISK with disc.state set to MD_DISK_CANDIDATE and
disc.number set to slot number)
ioctl(CLUSTERED_DISK_NACK)
6. Other nodes drop lock on "no-new-devs" (CR) if device is found
7. Node 1 attempts EX lock on "no-new-dev"
8. If node 1 gets the lock, it sends METADATA_UPDATED after
unmarking the disk as SpareLocal
9. If not (get "no-new-dev" lock), it fails the operation and sends
METADATA_UPDATED.
10. Other nodes get the information whether a disk is added or not
by the following METADATA_UPDATED.
6. Module interface
===================
There are 17 call-backs which the md core can make to the cluster
module. Understanding these can give a good overview of the whole
process.
6.1 join(nodes) and leave()
---------------------------
These are called when an array is started with a clustered bitmap,
and when the array is stopped. join() ensures the cluster is
available and initializes the various resources.
Only the first 'nodes' nodes in the cluster can use the array.
6.2 slot_number()
-----------------
Reports the slot number advised by the cluster infrastructure.
Range is from 0 to nodes-1.
6.3 resync_info_update()
------------------------
This updates the resync range that is stored in the bitmap lock.
The starting point is updated as the resync progresses. The
end point is always the end of the array.
It does *not* send a RESYNCING message.
6.4 resync_start(), resync_finish()
-----------------------------------
These are called when resync/recovery/reshape starts or stops.
They update the resyncing range in the bitmap lock and also
send a RESYNCING message. resync_start reports the whole
array as resyncing, resync_finish reports none of it.
resync_finish() also sends a BITMAP_NEEDS_SYNC message which
allows some other node to take over.
6.5 metadata_update_start(), metadata_update_finish(), metadata_update_cancel()
-------------------------------------------------------------------------------
metadata_update_start is used to get exclusive access to
the metadata. If a change is still needed once that access is
gained, metadata_update_finish() will send a METADATA_UPDATE
message to all other nodes, otherwise metadata_update_cancel()
can be used to release the lock.
6.6 area_resyncing()
--------------------
This combines two elements of functionality.
Firstly, it will check if any node is currently resyncing
anything in a given range of sectors. If any resync is found,
then the caller will avoid writing or read-balancing in that
range.
Secondly, while node recovery is happening it reports that
all areas are resyncing for READ requests. This avoids races
between the cluster-filesystem and the cluster-RAID handling
a node failure.
6.7 add_new_disk_start(), add_new_disk_finish(), new_disk_ack()
---------------------------------------------------------------
These are used to manage the new-disk protocol described above.
When a new device is added, add_new_disk_start() is called before
it is bound to the array and, if that succeeds, add_new_disk_finish()
is called the device is fully added.
When a device is added in acknowledgement to a previous
request, or when the device is declared "unavailable",
new_disk_ack() is called.
6.8 remove_disk()
-----------------
This is called when a spare or failed device is removed from
the array. It causes a REMOVE message to be send to other nodes.
6.9 gather_bitmaps()
--------------------
This sends a RE_ADD message to all other nodes and then
gathers bitmap information from all bitmaps. This combined
bitmap is then used to recovery the re-added device.
6.10 lock_all_bitmaps() and unlock_all_bitmaps()
------------------------------------------------
These are called when change bitmap to none. If a node plans
to clear the cluster raid's bitmap, it need to make sure no other
nodes are using the raid which is achieved by lock all bitmap
locks within the cluster, and also those locks are unlocked
accordingly.
7. Unsupported features
=======================
There are somethings which are not supported by cluster MD yet.
- change array_sectors.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
MD Cluster 개요
1-8Cluster MD는 cluster가 함께 사용하는 shared-device RAID입니다. 지원 RAID level은 `raid1`과 제한적으로 지원되는 `raid10`입니다.
문서가 전제로 삼는 공유 RAID 구성입니다.
1. On-disk format
9-34각 cluster node는 별도의 write-intent bitmap을 사용합니다. Bitmap에는 그 node에서 시작했지만 아직 끝나지 않았을 수 있는 모든 write가 기록됩니다.
디스크는 첫 4 KiB를 비워 두고 다음 4 KiB에 MD superblock을 둡니다. 이후 각 node의 `bm super[n]`과 bitmap bit를 이어 배치합니다. 아래 원문 block과 구조화 표는 같은 layout을 나타냅니다.
0 4k 8k 12k
-------------------------------------------------------------------
| idle | md super | bm super [0] + bits |
| bm bits[0, contd] | bm super[1] + bits | bm bits[1, contd] |
| bm super[2] + bits | bm bits [2, contd] | bm super[3] + bits |
| bm bits [3, contd] | | |원문 ASCII layout을 offset 순서대로 구조화했습니다.
정상 동작 중에는 filesystem이 임의의 block을 한 번에 한 node만 쓰도록 보장한다고 가정합니다. Write request는 필요한 bit를 set하고, 모든 mirror에 write를 commit한 뒤 timeout 후 해당 bit를 clear하도록 예약합니다.
Read는 일반 방식으로 처리합니다. 다른 node 또는 같은 node가 쓰고 있는 location을 동시에 읽지 않도록 보장하는 책임은 filesystem에 있습니다.
2. DLM lock과 bitmap lock resource
35-56Device 관리를 위한 lock은 bitmap lock resource, message passing lock, new-device management lock의 세 group으로 나뉩니다.
Cluster MD가 관리 목적으로 사용하는 세 lock group입니다.
`bm_lockres`는 개별 node bitmap을 보호합니다. Node 1은 `bitmap000`, node 2는 `bitmap001`처럼 이름을 붙입니다. Node가 cluster에 join하면 PW mode로 lock을 얻고 cluster member인 동안 유지합니다.
Lock resource number는 DLM subsystem이 돌려주는 slot number에 기반합니다. DLM node count는 1부터 시작하고 bitmap slot은 0부터 시작하므로 DLM slot number에서 1을 빼 bitmap slot number를 얻습니다.
특정 node의 bitmap lock LVB는 그 node가 resync 중인 sector range를 기록합니다. 다른 node는 그 sector에 쓸 수 없습니다. 이 정보는 새 node가 cluster에 join할 때 사용됩니다.
DLM slot을 bitmap slot과 lock resource로 변환하는 흐름입니다.
2.2 Message passing과 2.3 new-device lock
57-71각 node는 resync 시작·종료 및 metadata superblock update 때 다른 node와 통신해야 합니다. 이 통신은 `token`, `message`, `ack` 세 lock과 `message` lock 하나의 Lock Value Block(LVB)으로 관리합니다.
새 device 추가는 `no-new-dev` 단일 lock으로 조정하며 array 전체에서 synchronize해야 합니다. 평상시에는 모든 node가 이 resource에 concurrent-read lock을 보유합니다.
3. Communication
72-78Message는 모든 node에 broadcast할 수 있습니다. Sender는 진행하기 전에 다른 모든 node가 message를 acknowledge할 때까지 기다립니다. 동시에 처리할 수 있는 message는 하나뿐입니다.
3.1 Message types
79-124Cluster MD가 전달하는 message type은 여섯 가지입니다.
`METADATA_UPDATED`는 metadata가 바뀌었으므로 각 node가 MD superblock을 다시 읽어야 함을 알립니다. 동기적으로 처리하며 주로 device failure를 signal하는 데 사용합니다.
`RESYNCING`은 resync 시작 또는 종료를 알려 각 node가 해당 region을 suspend하거나 resume하게 합니다. Message에는 sender가 resync하려는 device range가 들어가며, 같은 node가 이전에 보낸 notification을 대체합니다. Node별로 한 번에 하나의 range만 resync할 수 있습니다.
`NEWDISK`는 device가 array에 추가되고 있음을 알리며 그 device identifier를 담습니다. `REMOVE`는 failed 또는 spare device의 제거를 알리며 device slot number를 담습니다.
`RE_ADD`는 다시 정상 동작한다고 판단한 failed device를 reactivate합니다. `BITMAP_NEEDS_SYNC`는 node가 local에서 stop했지만 bitmap이 clean하지 않을 때 다른 node가 resync ownership을 넘겨받도록 알립니다.
여섯 message의 payload와 효과를 정리했습니다.
3.2 Communication mechanism
125-148Cluster node 사이 통신에는 DLM LVB와 `token`, `message`, `ack` 세 resource를 사용합니다.
`token`은 전체 통신 system을 보호합니다. Token resource를 가진 node만 통신할 수 있습니다. `message` lock resource는 실제 전달 data를 담습니다.
`ack` resource의 획득은 cluster의 모든 node가 message를 acknowledge했다는 뜻입니다. 이 resource의 BAST는 어떤 node가 통신하려 한다는 사실을 receiver에 알립니다.
직렬화, payload 전달, 완료 확인을 각 resource가 분담합니다.
3.2 Communication algorithm
149-209초기 receive 상태에서는 모든 node가 `ack`에 concurrent-reader(CR) lock을 갖습니다.
sender receiver receiver
"ack":CR "ack":CR "ack":CRSender는 먼저 `token`과 `message`에 exclusive(EX) lock을 얻습니다. `token`을 기다리는 동안 받은 message나 다른 event 때문에 원래 message가 부적절하거나 중복이 되었을 수 있으므로, 이 시점에 여전히 보낼 필요가 있는지 다시 확인합니다.
sender receiver receiver
"token":EX "ack":CR "ack":CR
"message":EX
"ack":CRSender는 `message` LVB에 payload를 쓰고 `message`를 EX에서 concurrent-write(CW)로 down-convert한 다음 `ack`의 EX 획득을 시도합니다. `ack` BAST를 받은 receiver는 `message` CR을 얻어 LVB를 읽고 message를 처리한 뒤 `ack`를 release하고 `message` PR을 시도합니다.
[ wait until all receivers have *processed* the "message" ]
[ triggered by bast of "ack" ]
receiver get CR on "message"
receiver read LVB
receiver processes the message
[ wait finish ]
receiver releases "ack"
receiver tries to get PR on "message"
sender receiver receiver
"token":EX "message":CR "message":CR
"message":CW
"ack":EX모든 receiver가 message를 처리하면 sender에게 `ack` EX가 grant됩니다. Sender는 `ack`를 EX에서 CR로 down-convert하고 `message`, `token`을 release합니다. Receiver는 `message`를 PR로 up-convert하고 `ack` CR을 다시 얻은 뒤 `message`를 release하여 초기 상태로 돌아갑니다.
receiver upconvert to PR on "message"
receiver get CR of "ack"
receiver release "message"
sender receiver receiver
"ack":CR "ack":CR "ack":CR원문 lock state ASCII sequence를 하나의 처리 흐름으로 재구성했습니다.
Sender와 receiver의 핵심 상태를 비교합니다.
4.1 Node failure
210-246Node가 fail하면 DLM이 cluster에 slot number를 알리고 node는 cluster recovery thread를 시작합니다. 이 thread는 failed node의 `bitmap<number>` lock을 얻고 bitmap을 열어 읽은 뒤 set bit를 local node로 복사합니다. 이어 failed node bitmap을 clean하고 lock을 release한 다음 현재 node에서 그 bitmap의 resync를 시작합니다.
`recover_bitmaps` 안에서 `md_check_recovery`가 호출되고, `md_check_recovery -> metadata_update_start/finish`가 이어져 `lock_comm`으로 communication을 잠급니다. 따라서 한 node가 resync하는 동안 다른 모든 node의 array 전체 write가 block됩니다.
Resync 자체는 일반 MD resync이지만 clustered environment에서는 suspend할 area를 다른 node에 알려야 합니다. 시작 전 `(lo,hi)` range를 담은 `RESYNCING`을 보내고, 각 node는 받은 range를 `suspend_list`에 추가합니다. 완료 node가 empty range의 `RESYNCING`을 보내면 다른 node가 해당 entry를 제거합니다.
Helper function `->area_resyncing()`은 특정 I/O range를 suspend해야 하는지 검사합니다.
DLM failure 통지부터 resync 종료까지의 순서입니다.
4.2 Device failure
247-254Device failure는 metadata update routine으로 처리하고 전파합니다. 어떤 node가 device failure를 감지하면 다른 모든 node가 failure를 acknowledge할 때까지 그 device에 더 이상 write하지 못하게 합니다.
5. Adding a new device
255-281새 device를 추가하려면 모든 node가 그 device를 볼 수 있어야 합니다. Node 1의 `mdadm --manage /dev/mdX --add /dev/sdYY`는 `disc.state=MD_DISK_CLUSTER_ADD`인 `ioctl(ADD_NEW_DISK)`를 발생시킵니다.
Node 1은 uuid와 slot number를 담은 `NEWDISK`를 보냅니다. 다른 node는 같은 정보를 넣어 `kobject_uevent_env`를 발생시키고, userspace에서 `blkid -t SUB_UUID=""` 같은 방법으로 disk를 찾습니다. 이 두 단계는 udev rule로 구현할 수 있습니다.
Disk를 찾은 node는 `disc.state=MD_DISK_CANDIDATE`, `disc.number=slot number`인 `ioctl(ADD_NEW_DISK)`를 실행하고, 찾지 못한 node는 `ioctl(CLUSTERED_DISK_NACK)`를 실행합니다.
Device를 찾은 다른 node는 `no-new-devs`의 CR lock을 내려놓습니다. Node 1은 `no-new-dev` EX lock을 시도합니다. Lock을 얻으면 disk의 `SpareLocal` 표시를 제거한 뒤 `METADATA_UPDATED`를 보내고, 얻지 못하면 operation을 fail시킨 뒤 역시 `METADATA_UPDATED`를 보냅니다. 다른 node는 뒤따르는 message로 추가 성공 여부를 알게 됩니다.
모든 node가 새 disk를 확인하고 동의하는 절차입니다.
6. Module interface와 join·leave
282-296MD core가 cluster module에 호출할 수 있는 callback은 17개입니다. 이 interface를 이해하면 전체 처리 흐름을 파악할 수 있습니다.
Clustered bitmap으로 array를 시작할 때 `join(nodes)`가, array를 stop할 때 `leave()`가 호출됩니다. `join()`은 cluster 가용성을 확인하고 여러 resource를 initialize합니다. Cluster의 처음 `nodes`개 node만 array를 사용할 수 있습니다.
6.2 slot_number()
297-302`slot_number()`는 cluster infrastructure가 알려 준 slot number를 보고합니다. 범위는 0부터 `nodes-1`까지입니다.
6.3 resync_info_update()
303-310`resync_info_update()`는 bitmap lock에 저장된 resync range를 갱신합니다. Resync 진행에 따라 시작점은 이동하지만 끝점은 항상 array의 끝입니다. 이 callback 자체는 `RESYNCING` message를 보내지 않습니다.
6.4 resync_start()와 resync_finish()
311-321`resync_start()`와 `resync_finish()`는 resync, recovery 또는 reshape가 시작하거나 멈출 때 호출됩니다. 두 callback은 bitmap lock의 resyncing range를 갱신하고 `RESYNCING` message도 보냅니다.
`resync_start()`는 array 전체가 resync 중이라고 보고하고 `resync_finish()`는 resync 중인 영역이 없다고 보고합니다. `resync_finish()`는 다른 node가 작업을 넘겨받을 수 있도록 `BITMAP_NEEDS_SYNC`도 보냅니다.
6.5 Metadata update callback
322-330`metadata_update_start()`는 metadata에 exclusive access를 얻는 데 사용합니다. Access를 얻은 뒤에도 변경이 필요하면 `metadata_update_finish()`가 다른 모든 node에 `METADATA_UPDATE` message를 보냅니다. 변경이 필요 없으면 `metadata_update_cancel()`로 lock을 release합니다.
6.6 area_resyncing()
331-345`area_resyncing()`은 두 기능을 결합합니다. 첫째, 어느 node든 주어진 sector range의 일부를 resync 중인지 검사합니다. Resync를 찾으면 caller는 그 range에서 write 또는 read-balancing을 피합니다.
둘째, node recovery 중에는 READ request에 대해 모든 area가 resync 중이라고 보고합니다. 이로써 node failure를 처리하는 cluster filesystem과 cluster RAID 사이의 race를 피합니다.
I/O가 resync 또는 recovery와 충돌하지 않도록 판단합니다.
6.7 New disk callback
346-357`add_new_disk_start()`, `add_new_disk_finish()`, `new_disk_ack()`는 앞에서 설명한 new-disk protocol을 관리합니다. 새 device를 array에 bind하기 전에 `add_new_disk_start()`를 호출하고, 성공했다면 device가 완전히 추가된 뒤 `add_new_disk_finish()`를 호출합니다.
이전 request에 대한 acknowledge로 device가 추가되었거나 device를 unavailable로 선언할 때 `new_disk_ack()`를 호출합니다.
새 device protocol의 callback boundary입니다.
6.8 remove_disk()와 6.9 gather_bitmaps()
358-370`remove_disk()`는 spare 또는 failed device를 array에서 제거할 때 호출되며 다른 node에 `REMOVE` message를 보냅니다.
`gather_bitmaps()`는 다른 모든 node에 `RE_ADD` message를 보낸 뒤 모든 bitmap의 정보를 모읍니다. 결합한 bitmap은 다시 추가한 device를 recover하는 데 사용합니다.
6.10 모든 bitmap lock
371-379`lock_all_bitmaps()`와 `unlock_all_bitmaps()`는 bitmap을 none으로 바꿀 때 호출됩니다. 어떤 node가 cluster RAID bitmap을 clear하려면 다른 node가 RAID를 사용하지 않는지 확인해야 합니다. 이를 위해 cluster 안의 모든 bitmap lock을 잠그고 작업 후 그 lock을 모두 해제합니다.
7. Unsupported features
380-385Cluster MD가 아직 지원하지 않는 기능이 있으며, 이 문서가 명시하는 항목은 `array_sectors` 변경입니다.
요약과 해설
md-cluster.rst:1-385Cluster MD는 node별 write-intent bitmap과 DLM resource를 조합해 shared RAID를 운영합니다. `token/message/ack` handshake로 metadata와 resync 상태를 모든 node에 동기화하고, node failure 때 failed bitmap을 인계해 resync하며, 새 disk는 모든 node가 발견·승인한 뒤에만 array에 편입합니다.
핵심 안전성 경계는 filesystem의 block-level write serialization, bitmap lock LVB의 resync range, 모든 receiver가 처리할 때까지 기다리는 `ack` barrier입니다. Module callback은 이 protocol을 MD core의 resync, metadata update, disk add/remove lifecycle에 연결합니다.