원본은 RAID 1 구성원 두 개를 더 큰 디스크로 교체해도 **사용 가능한 파일 시스템이 자동으로 확장되지 않음**을 보여 줍니다. 한 사용자가 500GB 디스크 두 개를 한 번에 하나씩 1TB 디스크로 성공적으로 교체하고, 각 교체 후 ZimaOS가 재구성하도록 했습니다. 이 시점에서 두 물리 구성원은 모두 1TB였지만 RAID/장치와 Btrfs 파일 시스템은 여전히 이전 500GB 용량만 노출했습니다.
ZimaOS+ 1.5.4에서는 해당 사용자가 SSH를 통해 확장을 완료했습니다. mdadm --grow /dev/md0 --size=max를 실행하고, 그 결과로 발생한 복구/재동기화가 완료될 때까지 기다린 다음, 마지막으로 실행했습니다. btrfs filesystem resize max 마운트된 파일 시스템을 대상으로 실행했습니다. 사용자는 GUI와 df 그다음 더 큰 용량이 표시되었습니다. 이는 강력한 커뮤니티 검증이지만, 현재 IceWhale GUI 절차가 아닌 수동 CLI 워크플로입니다.
용량 확장을 시작하기 전에 백업하세요.
RAID 1은 구성원 하나의 장애를 보호하지만, 운영자 실수, 배열 메타데이터 손상, 파일 시스템 오류 또는 재구성 중 발생하는 두 번째 디스크 문제까지 보호하지는 않습니다.
한 번에 RAID 구성원 하나만 교체하세요.
- 전원을 끄세요.
- 첫 번째 기존 디스크를 더 큰 디스크로 교체하세요.
- 부팅하세요.
- ZimaOS 복구를 사용하여 재구성하세요.
- 복구가 완전히 완료될 때까지 기다리세요.
두 번째 구성원에 대해 반복
첫 번째 재구성이 완료된 후에야 사용자는 전원을 끄고 두 번째 디스크를 교체한 다음 GUI 복구를 다시 실행하고 완전히 완료될 때까지 기다렸습니다.
이 단계에서 배열은 두 개의 더 큰 물리 디스크에서 정상 상태였지만, 여전히 기존 구성원 크기를 기준으로 한 크기였습니다.
그 후 커뮤니티 사용자는 mdadm 배열을 확장했습니다.
원본 명령은 다음과 같습니다.
sudo mdadm --grow /dev/md0 --size=max새 배열 구성을 확인했습니다. mdadm --detail 새로운 복구/재동기화 상태가 완료될 때까지 기다렸습니다.
배열이 다음이라고 절대 가정하지 마세요: /dev/md0; 먼저 실제 배열을 식별하세요.
그다음 Btrfs 파일 시스템을 확장해야 했습니다.
원본에서는 다음 명령이 완료되었습니다.
sudo btrfs filesystem resize max /your/mounted/filesystem자리 표시자를 그대로 복사하지 말고 실제로 마운트된 Btrfs 경로를 사용하세요.
두 번의 크기 조정이 필요했던 이유
- Linux md RAID 장치;
- 그 위에 위치한 Btrfs 파일 시스템.
두 요소 모두 사용자가 추가 용량을 볼 수 있기 전에 더 큰 크기를 노출해야 합니다.
버전별 커뮤니티 절차로 취급
소스 사용자는 ZimaOS+ 1.5.4를 명시적으로 실행했습니다. 현재 ZimaOS는 더 최신 버전이며 스토리지 관리 동작은 변경될 수 있습니다. 수동 작업을 실행하기 전에 mdadm --grow 프로덕션 스토리지에서는 UI에 지원되는 확장 경로가 여전히 없는지 확인하고, 현재 절차에 대해 IceWhale 지원팀에 문의하는 것을 고려하세요.
각 물리적 교체 전에 RAID 상태 확인
첫 번째 디스크를 교체하기 전과 두 번째 디스크를 교체하기 전에 배열이 정상이고 완전히 동기화되었는지 확인하세요. 첫 번째 리빌드가 완료되기 전에 두 번째 교체를 시작하면 업그레이드 중에 의존하는 이중화가 사라집니다.
구성원 일련 번호를 기록하여, 제거하는 물리 드라이브가 ZimaOS에 표시되는 논리 구성원과 일치하는지 확인하세요.
교체 드라이브에는 충분한 실제 용량이 필요함
명목상 용량이 같은 드라이브라도 실제 사용 가능한 섹터 수는 약간 다를 수 있습니다. 가장 안전한 확장 방법은 기존 구성원보다 확실히 크고 서로 간에도 용량이 같거나 더 큰 교체 디스크를 사용하는 것입니다.
두 번째 “1TB” 드라이브가 첫 번째 드라이브보다 아주 조금이라도 작다면 md 확장/리빌드 단계가 예상대로 작동하지 않을 수 있습니다.
재동기화 주기가 한 번 이상일 수 있음
소스의 워크플로에서는 첫 번째 물리 디스크 교체 후 리빌드가 진행되고, 두 번째 교체 후 다시 리빌드가 진행된 다음, 다시 복구/재동기화 상태에 들어갔습니다. mdadm --grow. 즉, 용량 업그레이드에는 단순히 디스크 두 개를 교체하는 것보다 훨씬 더 오래 걸릴 수 있습니다.
모든 복구 단계 동안 NAS를 안정적인 전원에 연결하고 불필요한 재시작을 피하세요.
마지막에 블록 장치와 파일 시스템 모두 확인
최종 Btrfs 크기 조정 후에는 둘 이상의 계층에서 결과를 확인하세요.
-
mdadm --detail— md RAID 구조; -
df -h또는 Btrfs 파일 시스템 도구 — 사용 가능한 파일 시스템 용량; - ZimaOS 스토리지 UI — 예상 풀 크기 및 정상 상태.
어느 한 계층에서든 이전 크기가 계속 표시되면, 확장 명령을 무작정 반복하지 말고 중지한 후 원인을 조사하세요.
RAID 1 확장 FAQ
더 큰 디스크 하나만으로 RAID1 용량을 즉시 늘릴 수 있나요?
아니요. 미러는 더 작은 구성원과 기존 배열 구조에 의해 제한됩니다.
소스에서 더 작은 디스크 두 개를 모두 교체하면 용량이 자동으로 늘어났나요?
아니요. 사용자는 먼저 md 배열을 확장한 다음 Btrfs 크기를 조정해야 했습니다.
수동 확장 워크플로가 출처를 통해 확인된 것인가요?
예, ZimaOS+ 1.5.4 사용자 한 명이 수행했습니다. 공식 IceWhale 절차로 게시된 내용은 아닙니다.
