원래는 약 3.5TiB 크기의 단일 가상 디스크 파일(.qcow2)이 있었는데 여러 가지 이유로 유사한 모든 데이터를 자체 가상 디스크 파일에 "그룹화"하기로 결정했습니다. 이는 분명히 원본 디스크 파일을 900GiB로 줄일 수 있음을 의미하지만 ls친구들 stat은 여전히 원본 3.5TiB를 나열합니다.
$ ls -lhks mydisk.qcow2
722G -rw-r--r-- 1 root root 3.5T Aug 6 18:06 mydisk.qcow2
물론 파일 시스템 자체(ext4)를 축소한 후 파일을 솎아냈기 때문에 현재 722GiB만 할당되어 있습니다. 하지만 내 백업 도구는 여전히 3.5TiB를 감지하므로 전체 데이터를 검색하고 디스크 자체는 900GiB만 저장할 수 있으므로 완료하는 데 거의 4배의 시간이 걸립니다.
보고서의 차원을 어떻게 "새로 고침"합니까? 이것은 HDD가 있는 머신이므로 파일이 너무 조각화되어 있고 3.5TiB 정도의 크기를 가지고 있는 것 같습니다. 하지만 파일을 복사하면 이 문제가 자동으로 해결되지 않을까요? (시도했지만 적어도 해결되지는 않았습니다) 또한 중요한 경우 디스크 파일 자체도 ZFS에 있습니다.
가능하다면 어떤 해결책이라도 더 좋을 것입니다.제자리에. 잠시 동안 디스크를 사용하여 가상 머신을 종료하는 것은 문제가 되지 않습니다.
답변1
이 작업을 내부에서 수행하는 방법에는 여러 가지가 있는 것 같습니다.
zerofree [-v] /dev/vdXY내부에서 사용됨손님VM(Linux라면 내 것은 둘 다임)을 찾으려면0이 아닌 할당되지 않음블록("제거된" 것)을 0으로 대체합니다.fallocate --dig-holes mydisk.qcow2팔로우주인0을 구멍으로 바꿉니다. 호스트의 파일 시스템에 따라 후자가 필요하지 않을 수도 있지만 압축이 활성화되면 ZFS가 자동으로 이를 희소로 처리할 것이라고 생각합니다.- 그냥 사용해도
virt-sparsify --in-place mydisk.qcow2제로잉과 펀칭 모두 효과가 있는 것 같습니다. 내가 아는 한, libguestfs에서 트림/삭제/매핑 해제 지원이 필요합니다. 하지만 버전이 너무 오래되지 않았다면 해당 버전이 있어야 합니다.
테스트를 위해 10GiB 디스크를 만들고 일부 텍스트 파일을 추가하고 나머지를 채운 dd if=/dev/urandom다음 마지막 파일을 삭제했습니다. 할당된 것을 du -h확인하세요 9.8G. 그런 다음 일부 가상 디스크를 직접 복사하여 개별적으로 테스트했습니다.
- ZFS 압축을 사용하고 있으므로
zerofree이 압축은 1173kB(1200640바이트)로 줄었습니다.fallocate아무것도 변경되지 않습니다(예상). - 한 단계 더 나아가 875kB(895488바이트)에 도달합니다.
zerofree이 경우 ZFS 압축이 약간 비효율적인지 여부를 말하기는 어렵습니다 . 그런데 virt-sparsify호스트의 명령이고 속도도 빠른 것 같아서 그냥 사용합니다.