디스크가 죽어도 파일은 살아 있습니다.

01

패리티는 같은 줄의 값들을 XOR 한 것입니다.

각 스트라이프마다 데이터 블록 세 개를 XOR 해서 네 번째 디스크에 적습니다. XOR 은 같은 값을 두 번 적용하면 원래대로 돌아오는 성질이 있어서, 네 값 중 어느 하나가 없어도 나머지 셋을 XOR 하면 사라진 값이 그대로 나옵니다. 화면이 기록 단계와 복구 단계에서 같은 모양의 계산 패널을 쓰는 것은 두 작업이 사실 같은 연산이기 때문입니다.

02

한 줄에 구멍이 하나일 때만 통합니다.

복구가 가능한 조건은 스트라이프 한 줄에서 모르는 값이 하나뿐일 때입니다. 미지수가 하나인 식은 풀리지만 둘이면 풀리지 않는 것과 같습니다. 디스크 두 대가 죽으면 모든 줄에 구멍이 두 개씩 생기므로 어느 줄도 복구할 수 없고, 화면의 두 번째 시나리오가 보여주는 것이 정확히 그 상황입니다. 디스크가 한 대만 더 있으면 되는 문제가 아니라 계산 자체가 불가능해집니다.

03

고장 난 상태로도 파일은 열립니다.

디스크 한 대가 죽어도 읽기 요청은 실패하지 않습니다. 대신 요청할 때마다 남은 값들을 XOR 해서 없는 블록을 그때그때 만들어 냅니다. 파일은 온전하지만 읽을 때마다 계산이 붙으므로 느려지고, 화면에서 이 구간을 따로 표시해 둔 이유도 정상 동작과 구분하기 위해서입니다. 겉으로 멀쩡해 보여서 고장을 오래 방치하게 되는 것이 이 상태의 위험입니다.

04

교체 후 다시 채우는 것도 같은 계산입니다.

새 디스크를 꽂으면 빈 블록을 하나씩 XOR 로 계산해 채웁니다. 이 작업은 남은 모든 디스크를 처음부터 끝까지 읽어야 하므로 오래 걸리고 부하도 큽니다. 그리고 그동안 시스템은 여전히 여유가 없는 상태라, 이 시점에 다른 디스크가 하나 더 죽으면 앞의 두 번째 시나리오와 같은 결과가 됩니다.

05

단계마다 상태를 통째로 복사해 둡니다.

각 단계는 디스크 네 대의 상태를 자기만의 사본으로 들고 있습니다. 앞뒤로 넘겨도 값이 섞이지 않게 하려면 단계끼리 같은 객체를 공유하면 안 되기 때문입니다. 되돌리기를 눌렀을 때 이미 복구된 블록이 남아 있거나 하는 문제가 생기지 않는 것이 이 구조 덕분이고, 자동 테스트도 단계별 스냅샷을 하나씩 확인합니다.

06

블록 값은 눈으로 따라갈 수 있게 골랐습니다.

아홉 개 블록에 들어 있는 값은 16진수 두 자리로 표시되고, 화면에서 2진수로도 볼 수 있습니다. XOR 을 자리별로 비교하려면 8비트 정도가 눈으로 따라가기에 적당하기 때문입니다. 실제 디스크는 훨씬 큰 단위로 블록을 다루지만, 계산 규칙 자체는 크기와 무관하게 같습니다.

07

복구와 백업은 다른 문제입니다.

이 구조가 막아 주는 것은 디스크라는 장치가 고장 나는 상황 하나뿐입니다. 파일을 실수로 지우거나 잘못된 내용으로 덮어썼다면 그 변경이 패리티까지 함께 갱신되므로, 어느 디스크를 살려 내도 지워진 파일은 돌아오지 않습니다. 마지막 단계에 백업이 따로 필요하다는 문장을 붙여 둔 이유이고, 그 주제는 다음 편이 이어받습니다.

08

쓸 때마다 패리티도 함께 고쳐야 합니다.

블록 하나를 바꾸면 그 줄의 패리티도 다시 계산해 적어야 합니다. 그래서 작은 수정이 잦은 작업에서는 읽기와 쓰기가 예상보다 여러 번 일어납니다. 화면에서는 스트라이프를 한 번에 통째로 기록하므로 이 비용이 드러나지 않지만, 실제 운용에서 이 구성이 읽기에 비해 쓰기가 느린 이유가 여기 있습니다.