얼마 전 흥미로운 상황에 직면했습니다. /backup에 1TB NFS 파일 시스템이 마운트되어 있습니다. df보고된 총 크기는 예상대로 약 1TB입니다.
그러나 du -csh ./backup/.snapshot 디렉터리에서 실행하면 3.0TB의 데이터가 보고되었습니다.
나는 du가 마운트 지점보다 큰 전체 크기로 출력을 생성하는 것을 본 적이 없습니다. 이 NFS 공유는 NetApp 장치에서 제공됩니다. .snapshot 디렉터리는 NetApp에서 생성되었으며 공간의 5%를 사용하도록 구성되어 있는 것으로 알려졌습니다. (물론 공간을 300% 활용하는 것은 불가능합니다)
이것이 Linux 문제입니까, NFS 문제입니까, NetApp 문제입니까, 아니면 다른 문제입니까? 어떤 다른 데이터를 제공할 수 있나요?
운영체제는 CentOS 6입니다.
답변1
한동안 NetApp을 사용하지 않았기 때문에 절대적인 권위로 답변할 수는 없지만 이러한 유형의 동작에 대한 설명은 제공할 수 있습니다.
Linux의 LVM 작동 방식과 매우 유사하게 작동하는 것 같습니다. LVM 볼륨 그룹에 100% 매핑된 1TB 물리 디스크가 있다고 가정합니다. 이제 볼륨 그룹에 100GB 논리 볼륨을 생성합니다. 일부 작업을 수행하고 일부 파일을 배치하는 등의 작업을 수행합니다. 그런 다음 논리 볼륨의 스냅샷을 생성합니다. 이제 논리 볼륨에서 수정된 모든 파일(실제로는 블록)이 복사되므로 스냅샷에서 원본 데이터에 액세스할 수 있습니다. 하지만 이 스냅샷을 찍어 일반 볼륨처럼 마운트할 수도 있습니다. 마운트하면 이제 2개의 100GB 파일 시스템이 마운트됩니다. 그러나 두 파일 시스템 모두 파일 시스템 중 하나의 데이터가 변경될 때까지 동일한 데이터(물리적 볼륨 블록)를 공유합니다.
따라서 NetApp이 할 수 있는 일은 /backup/.snapshot카탈로그를 통해 이러한 스냅샷에 대한 액세스를 제공하는 것입니다. 분석 결과 각 스냅샷은 원본 볼륨과 동일한 크기로 나타납니다.
이상하게 보일 수도 있지만 (NFS, 커널 등에 관한 한) 완전히 합법적입니다. 를 실행하면 df시스템은 "이 파일 시스템의 크기"를 알려주는 NFS 호출을 수행하고 원격 시스템은 필요에 따라 응답할 수 있습니다. 그런 다음 을 수행하면 du시스템은 "이 파일의 크기"를 알려주는 NFS 호출을 수행하고 원격 시스템은 필요에 따라 응답할 수 있습니다.
스파스 파일에 대해 유사한(동일하지는 않음) 작업을 수행할 수도 있습니다. 파일은 실제보다 더 많은 공간을 차지한다고 합니다.
오늘날에는 파일 시스템 공간을 절약하는 고급 방법이 많이 있습니다. "내가 가지고 있는 공간이 얼마나 됩니까?" 또는 "이 파일이 차지하는 공간이 얼마나 됩니까?"라는 질문에 항상 간단한 답이 있는 것은 아닙니다. 스냅샷, 중복 제거, 투명한 압축 등을 사용할 수 있습니다.