나는 ZFS를 실험해왔고 마침내 그것이 화상을 입어서는 안 될 만큼 충분히 성숙했다는 것을 인정했습니다.
이제 마이그레이션을 하기 위해 현재 LVM JBOD 설정인 홈 NAS 박스가 꽉 차 있는데 한 드라이브에 할당되지 않은 공간이 꽤 있습니다.
저는 스파스 파일에 생성된 zpool을 사용하여 zfs를 실험해 왔습니다. 파일 기반 가상 장치를 물리적 파티션으로 교체하는 것은 매우 유연한 접근 방식처럼 보입니다.
이 아이디어를 극단적으로 적용하여 이미 매우 가득 찬 이 파일 시스템에서 기존 하드웨어와 동일한 크기의 희소 파일 vdev를 만들고 내용을 LVM에서 ZFS 배열로 이동하면 어떻게 될지 궁금합니다.
이론적으로 LVM 파일 시스템에 증가하는 ZFS를 수용할 수 있는 충분한 여유 공간이 있는 한 파일이 삭제되어도 계속 작동해야 합니다. 그러면 LVM 파일 시스템은 실제 ZFS 이미지를 제외하고 결국 비어 있게 되며 물리 파티션으로 교체될 수 있습니다.
조각화는 적어도 성능에 심각한 영향을 미칠 것으로 예상됩니다.
표면적으로 이것은 완전히 미친 소리처럼 들립니다. 동일한 파일 시스템의 다른 컨테이너에 파일을 복사하려는 이유는 무엇입니까? 따라서 저는 이 데이터 세트가 중복 제거와 압축을 전환하면 이점을 얻을 수 있다고 생각하므로 더 많은 여유 공간을 확보할 수 있습니다. 그러나 주요 목표는 "드라이브"를 업그레이드할 수 있는 ZFS 풀에 데이터를 저장할 수 있는 유연성을 얻는 것입니다. 즉, 물리적 하드웨어로 교체하는 것입니다.
이 미친 질문은 다음에서 영감을 얻었습니다.이 블로그 게시물루프백 장치를 임시 하드 디스크 교체용으로 사용하여 어레이의 RAID 레벨을 변환하십시오.
답변1
기존 파일 시스템에 zpool을 파일로 배치한다는 것은 해당 파일 시스템에 의존하여 일관성을 제공하고(위험해 보임) ZFS가 캐시를 최대한 활용할 수 없음을 의미합니다. ZFS가 파일에서 물리적 장치로의 전송을 얼마나 잘 처리하는지 잘 모르겠습니다.아마도실제 불만은 없지만 vdev를 더 작은 장치로 좋아하지 않는 것과 같은 문제에 직면할 수 있습니다. (내가 읽은 바에 따르면 많은 사람들이 이 설정으로 인해 괴로워하므로 autoexpand=on해당 속성에 주의하고 싶을 수도 있습니다. 그 테이블 남동생 autoreplace). 또는 LVM 위에서 ZFS를 실행할 수도 있습니다. 이는 가능할 수도 있지만 ZFS는 대용량 장치만 볼 수 있으므로 장치를 지능적으로 처리하는 것을 허용하지 않습니다. ZFS는 단순한 파일 시스템이 아니라 볼륨 관리자이기도 하므로 올바르게 교체하십시오.둘 다일반 파일 시스템 및 LVM. 여러 디스크에 메타데이터를 배치하고 중복성을 위해 zpool 내에 여러 데이터 복사본을 배치하는 것을 포함한 많은 ZFS 기능은 물리적 저장소 레이아웃을 잘 이해할 때 가장 잘 작동합니다.
나는 또한 ZFS로의 마이그레이션에 대해 생각하고 있었습니다.내가 생각할 수 있는 최선의 선택마이그레이션에는 하드 드라이브가 하나 더 필요합니다. 현재 어레이에 있는 가장 작은 물리적 드라이브와 크기가 최소한 같은 다른 하드 드라이브를 설치하고 여기에 ZFS 풀과 파일 시스템을 만든 다음(JBOD로 구성되지만 장치는 하나만 있음) 최대한 많은 데이터를 이동합니다. 가능한 한 이 하드 드라이브로 이동할 수 있습니다. (LVM을 실행하지 않으므로 min 드라이브의 모든 항목을 ZFS fs로 이동하겠습니다.) 물리적 디스크 하나를 제거하여 LVM 배열을 줄이고 ZFS zpool을 이제 사용 가능한 디스크로 확장한 다음 일부 파일을 이동합니다. , 헹구고 완료될 때까지 반복합니다. 심볼릭 링크를 현명하게 사용하거나 내보내기를 잘 처리하면 NAS 상자에 있는 파일을 동시에 사용하는 모든 사람에게 프로세스를 투명하게 만들 수도 있습니다.