이전에 본 적이 없는 이상한 문제가 있습니다. 약 1.7Gb의 크기를 보고하는 ZFS 볼륨이 있는데 스냅샷도 마찬가지입니다. 그런 다음 zfs가 백업을 보내려고 하면 큰 파일을 얻습니다. 자동 백업 gzip으로 인해 12Gb 파일이 생성되고 방금 테스트했을 때(gzip 없이) 파일이 다음 크기로 커지면 파일 크기가 커집니다. 66Gb를 중단한 후 - 중복된 데이터가 많다는 뜻입니다. 여기서 무슨 일이 일어나고 있는 걸까요? 분열? 그렇다면 어떻게 해야 합니까?
# zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
lxd 476G 64.8G 411G - 60% 13% 1.00x ONLINE -
용량:
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
lxd 64.8G 396G 24K none
...
lxd/containers/cdinspector 993M 1.32G 1.68G /var/snap/lxd/common/lxd/storage-pools/lxd/containers/cdinspector
스냅 사진:
# zfs list -t snapshot
NAME USED AVAIL REFER MOUNTPOINT
lxd/containers/cdinspector@test 1.39M - 1.68G -
목록-r
# zfs list -r lxd/containers/cdinspector
NAME USED AVAIL REFER MOUNTPOINT
lxd/containers/cdinspector 1.05G 1.31G 1.69G /var/snap/lxd/common/lxd/storage-pools/lxd/containers/cdinspector
스트리밍 볼륨 명령:
# zfs send lxd/containers/cdinspector@test | /usr/bin/mbuffer -m 500M > /backup/test
답변1
문제의 근본 원인은 ZFS 압축인 것으로 밝혀졌습니다. 관련 클라이언트의 컨테이너에는 좀비 vim 프로세스가 실행되고 있으며, 이 프로세스는 swp 파일에 중복 데이터를 지속적으로 기록합니다.
ZFS 압축은 실제로 작동합니다! 소비된 논리적 공간은 약 2.4Tb이며 압축률은 최대 1700x이며 ZFS는 이를 물리적 공간의 약 1.7Gb로 줄입니다.
문제를 정확하게 설명하는 문서는 다음을 참조하세요.
https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSCompressionAndQuotas
우리는 또한 zfs 압축을 비활성화하는 것을 고려하고 있습니다. 왜냐하면 우리가 설계한 방식으로 인해 이것이 우리에 대한 잠재적인 DOS 공격의 통로가 되기 때문입니다(비록 이것은 우리가 눈치채지 못하도록 하는 매우 느리고 다소 모호한 공격이지만).