디스크 사용량을 측정하는 방법이 왜 그렇게 다양합니까?

숫자를 추가하는 것은 쉽습니다. 문제는 추가해야 할 숫자가 너무 많다는 것입니다.

파일은 얼마나 많은 디스크 공간을 사용합니까?

기본 아이디어는N바이트 사용량N바이트의 디스크 공간과 일부 제어 정보(파일의 메타데이터(권한, 타임스탬프 등)) 및 파일이 저장된 정보를 찾는 시스템에 대한 약간의 오버헤드가 필요합니다. 그러나 많은 합병증이 있습니다.

미세한 합병증

각 파일을 도서관에 있는 일련의 책으로 생각하세요. 작은 파일은 한 권으로 구성되지만, 큰 파일은 백과사전처럼 여러 권으로 구성됩니다. 파일을 찾을 수 있도록 각 볼륨을 참조하는 카드 디렉토리가 있습니다. 각 권에는 표지로 인해 약간의 오버헤드가 있습니다. 파일이 작은 경우 이 오버헤드는 상대적으로 큽니다. 카드 카탈로그 자체도 약간의 공간을 차지합니다.

좀 더 기술적으로, 일반적인 단순 파일 시스템에서는 공간이 다음과 같이 나뉩니다.조각. 일반적인 블록 크기는 4KiB입니다. 각 파일은 정수 개의 블록을 차지합니다. 파일 크기가 블록 크기의 배수가 아닌 이상 마지막 블록만 부분적으로 사용됩니다. 따라서 1바이트 파일과 4096바이트 파일은 모두 1블록을 차지하고, 4097바이트 파일은 2블록을 차지합니다. 다음을 사용하거나 ls관찰 할 수 있습니다 du. 파일 시스템의 블록 크기가 4KiB인 경우 ls -s및 du는 1바이트 파일을 4KiB로 보고합니다.

파일이 큰 경우 파일을 구성하는 블록 목록을 저장하려면 추가 블록이 필요합니다.간접 차단;더 복잡한 파일 시스템은 이를 다음 형식으로 최적화할 수 있습니다.범위). 이는 ls -lGNU나 GNU에서 보고한 파일 크기에는 표시되지 않습니다 du --apparent-size. 크기 du대신 ls -s디스크 사용량을 보고하면 이러한 문제가 잘 드러납니다.

일부 파일 시스템은 마지막 블록에 남아 있는 여유 공간을 재사용하려고 합니다.동일한 블록에 여러 파일 테일을 패킹합니다.. 일부 파일 시스템(예:Linux 3.8 이후의 ext4inode에 완벽하게 맞는 작은 파일(단 몇 바이트)에는 0 블록을 사용합니다.

거시적 합병증

일반적으로 위에 표시된 대로 보고된 총 크기는 du파일에서 사용되는 블록 또는 범위 크기의 합계입니다.

du파일이 압축된 경우 보고된 크기가 더 작을 수 있습니다. Unix 시스템은 전통적으로 조잡한 형태의 압축을 지원했습니다. 파일 블록에 널 바이트만 포함된 경우 파일 시스템은 0 블록을 저장하는 대신 블록을 완전히 무시할 수 있습니다. 이와 같은 블록을 생략한 파일을스파스 파일. 파일에 많은 수의 널 바이트가 포함되어 있으면 스파스 파일이 자동으로 생성되지 않으며 애플리케이션은 파일이 스파스되도록 준비해야 합니다.

일부 파일 시스템, 예:BTFS그리고지브스보편적인 지원압축.

후기 합병증

zfs 및 btrfs와 같은 최신 파일 시스템의 두 가지 주요 기능인 스냅샷과 중복 제거는 파일 크기와 디스크 사용량 간의 관계를 더욱 멀게 만듭니다.

스냅 사진특정 날짜에 파일 시스템이 정지된 상태입니다. 이 기능을 지원하는 파일 시스템에는 서로 다른 날짜에 촬영된 여러 스냅샷이 포함될 수 있습니다. 물론 이러한 스냅샷은 공간을 차지합니다. 극단적인 경우는 파일 시스템의 활성 버전에서 모든 파일을 삭제하는 경우 스냅샷이 남아 있어도 파일 시스템이 비어 있지 않게 되는 것입니다.

스냅샷이 생성된 이후 또는 두 스냅샷 사이에 변경되지 않은 파일이나 블록은 스냅샷과 활성 버전 또는 다른 스냅샷 모두에 동일하게 존재합니다. 이는 다음에 의해 달성됩니다.쓰기 중 복사. 일부 극단적인 경우에는 여유 공간이 부족하여 전체 파일 시스템에서 파일을 삭제하는 데 실패할 수 있습니다. 파일을 삭제하려면 디렉터리에 블록을 복사해야 하고 해당 블록에도 더 이상 공간이 없기 때문입니다.

중복 제거동일한 블록을 저장하지 않는 저장 최적화 기술입니다. 일반적인 데이터의 경우 중복 항목을 찾는 것이 항상 노력할 가치가 있는 것은 아닙니다. 둘 다지브스그리고BTFS선택적 기능으로 중복 제거를 지원합니다.

전체 크기가 du파일 크기의 합과 다른 이유는 무엇입니까?

위에서 본 것처럼 각 파일에 대해 보고된 크기는 du일반적으로 파일에서 사용되는 블록 또는 범위의 크기를 합한 것입니다. 기본적으로 ls -l크기는 바이트 단위로 나열되지만 du일부 기존 시스템에서는 KiB 또는 512바이트 단위(섹터)로 나열됩니다( du -k킬로바이트는 필수임). 대부분의 최신 유니스는 "사람이 읽을 수 있는" 숫자를 지원 ls -lh하고 du -h사용합니다. K, M, G 등을 사용하는 것만으로도 충분합니다(KiB, MiB, GiB의 경우).

du디렉터리에서 실행 하면 디렉터리 트리에 있는 모든 파일의 디스크 사용량이 요약됩니다.디렉토리 포함그들 자신. 디렉터리에는 데이터(파일 이름과 파일의 메타데이터가 있는 위치를 가리키는 포인터)가 포함되어 있으므로 약간의 저장 공간이 필요합니다. 작은 디렉터리는 한 블록을 차지하고, 큰 디렉터리에는 더 많은 블록이 필요합니다. 디렉터리에서 사용하는 저장 용량은 디렉터리에 포함된 파일뿐만 아니라 디렉터리가 삽입되는 순서와 특정 파일이 삭제되는 순서에 따라 달라지는 경우도 있습니다(일부 파일 시스템에서는 이로 인해 구멍이 남을 수 있음). 디스크 공간과 성능 간에 차이가 있음)), 차이는 미미합니다(여기서 추가 청크가 발생함). 를 실행하면 ls -ld /some/directory디렉토리 크기가 나열됩니다. (출력 상단의 "total NNN" 행은 ls -l관련 없는 숫자이며, KiB 또는 섹터로 표시되는 나열된 항목의 블록 크기 합계입니다.)

du여기에는 포함된다는 점을 명심하세요.파일 클릭ls-A또는 옵션을 사용하지 않으면 표시되지 않습니다 -a.

du신고된 금액이 예상 금액보다 적은 경우도 있습니다. 있었다면 이런 일이 일어났을 것이다하드 링크디렉터리 트리 내부: du각 파일은 한 번만 계산됩니다. 스위치를 사용하여 du -l파일 수 계산질소시간이 있다면질소하드 링크.

일부 파일 시스템(예: ZFSLinux) 에서는 du파일의 확장 속성이 차지하는 전체 디스크 공간이 보고되지 않습니다.

디렉토리 아래에 마운트 지점이 있는 경우 du옵션이 제공되지 않는 한 해당 마운트 지점의 모든 파일도 계산됩니다 -x. 따라서 루트 파일 시스템의 전체 파일 크기를 원하면 du -x /대신 실행하십시오 du /.

파일 시스템이 비어 있지 않은 디렉터리에 마운트된 경우, 이 디렉토리의 파일은 마운트된 파일 시스템에 의해 숨겨집니다. 그들은 여전히 ​​​​그들의 공간을 차지하고 있지만 du찾을 수 없습니다.

삭제된 파일

파일이 있을 때삭제됨, 파일 자체는 삭제하지 않고 디렉토리 항목만 삭제합니다. 실제로 파일을 삭제하고 디스크 공간을 회수하려면 두 가지 조건이 충족되어야 합니다.

• 파일의 링크 수는 0으로 줄여야 합니다. 파일에 여러 개의 하드 링크가 있는 경우 하나를 삭제해도 다른 링크에는 영향을 미치지 않습니다.
• 일부 프로세스에서 파일이 열려 있는 한 데이터는 유지됩니다. 파일은 모든 프로세스가 파일을 닫을 때만 삭제됩니다. 산출fuser -m또는lsof해당 파일 시스템에서 파일을 여는 프로세스는 파일이 삭제된 경우에도 마운트 지점에 포함됩니다.
• 삭제된 파일을 여는 프로세스가 없더라도 해당 파일이 기기의 백엔드인 경우 파일 공간을 회수하지 못할 수 있습니다 loop. losetup -a(예: )는 현재 어떤 장치가 어떤 파일에 설정되어 있는지 root알려줍니다 . 디스크 공간을 회수하려면 먼저 루프 장치를 파기(사용)해야 합니다.looplosetup -d

일부 파일 관리자나 GUI 환경에서 파일을 삭제하면 삭제 취소가 가능한 휴지통 영역에 들어갈 수 있습니다. 파일을 복구할 수 있는 한 해당 공간은 계속 소모됩니다.

이 숫자는 어디 df에서 왔습니까?

일반적인 파일 시스템에는 다음이 포함됩니다.

• 파일(디렉터리 포함) 데이터와 일부 메타데이터(일부 파일 시스템의 간접 블록 및 확장 속성 포함)를 포함하는 블록입니다.
• 무료 블록.
• 루트 사용자용으로 예약된 블록입니다.
• 슈퍼블록 및 기타 제어 정보.
• 인덱스 노드
• ㅏ잡지

첫 번째 유형만 보고되었습니다 du. 이 경우 df"사용됨", "사용 가능" 및 총계 열에 있는 내용은 파일 시스템에 따라 다릅니다(물론, 사용된 블록(간접 블록 포함)은 항상 "사용됨" 열에 있고 사용되지 않은 블록은 항상 " 사용 가능' 열).

ext2/ext3/ext4의 파일 시스템예약공간의 5%가 루트 사용자에게 제공됩니다. 이는 루트 파일 시스템이 시스템이 꽉 찼을 때 시스템을 계속 실행하는 데 유용합니다(특히 로깅의 경우 및 시스템 관리자가 문제를 해결하는 동안 일부 데이터를 저장할 수 있도록 허용). 와 같은 데이터 파티션의 경우에도 /home거의 가득 찬 파일 시스템이 쉽게 조각화될 수 있으므로 예약된 공간을 남겨 두는 것이 유용합니다. Linux는 파일을 작성할 때 많은 연속 블록을 사전 할당하여 조각화를 방지하려고 시도하지만(이로 인해 특히 하드 드라이브와 같은 회전식 기계 장치에서 파일 액세스 속도가 느려질 수 있음) 연속 블록이 많지 않으면 작동하지 않습니다.

기존 파일 시스템(ext4 포함, btrfs 제외)은 고정된 수의 파일 시스템을 예약합니다.인덱스 노드파일 시스템을 생성할 때. 이는 파일 시스템 설계를 상당히 단순화하지만 inode 수를 적절하게 조정해야 한다는 단점이 있습니다. inode가 너무 많으면 공간이 낭비되고, inode가 부족해지기 전에 파일 시스템에서 inode가 부족해질 수 있습니다. 공간의. 이 명령은 df -i사용 중인 inode 수와 사용 가능한 수를 보고합니다(이 개념이 적용되지 않는 파일 시스템은 0을 보고할 수 있음).

ext2/ext3/ext4 파일 시스템이 포함된 볼륨에서 실행하면 tune2fs -l사용 가능한 inode 및 블록의 총 개수와 개수를 포함한 일부 통계가 보고됩니다.

물질을 혼동할 수 있는 또 다른 특징은 다음과 같습니다.하위 볼륨(지원BTFS, 그리고 zfs의 이름 아래데이터 세트). 여러 하위 볼륨은 동일한 공간을 공유하지만 별도의 디렉터리 트리 루트를 갖습니다.

파일 시스템이 네트워크(NFS, Samba 등)를 통해 마운트되고 서버가 파일 시스템의 일부(예:서버에는 /home파일 시스템이 있고 내보내기/home/bob), 그런 다음 df클라이언트에 내보내어 설치한 부분뿐만 아니라 클라이언트의 전체 파일 시스템 데이터를 반영합니다.

내 디스크 공간은 어떤 용도로 사용되고 있나요?

위에서 본 것처럼 보고된 총 크기가 df항상 파일 시스템의 모든 제어 데이터를 고려하는 것은 아닙니다. 필요한 경우 파일 시스템별 도구를 사용하여 파일 시스템의 정확한 크기를 가져옵니다. 예를 들어, ext2/ext3/ext4의 경우 실행 tune2fs -l하고 블록 크기에 블록 수를 곱합니다.

파일 시스템이 생성되면 일반적으로 포함된 파티션이나 볼륨의 사용 가능한 공간이 채워집니다. 때로는 파일 시스템을 이동하거나 볼륨 크기를 조정할 때 파일 시스템이 더 작아질 수 있습니다.

Linux에서는 lsblk사용 가능한 스토리지 볼륨에 대한 좋은 개요가 제공됩니다. 자세한 정보를 원하거나 파티션이 없는 경우 lsblk특수 볼륨 관리 또는 파티셔닝 도구를 사용하여 어떤 파티션이 있는지 확인하세요. Linux에는 lvs, vgs, 가 pvs있습니다.좌심실 용적,fdisk기존 PC 스타일("MBR") 파티션(최신 시스템의 GPT)의 경우,gdisk~을 위한GPT분할,disklabelBSD 디스크 레이블의 경우헤어졌다리눅스에서 cat /proc/partitions간략하게 요약해 보겠습니다 . 일반적인 설치에는 운영 체제에서 사용하는 최소한 두 개의 파티션이나 볼륨, 즉 파일 시스템(경우에 따라 그 이상)과교환용량.

일부 컴퓨터에는 다음을 포함하는 파티션이 있습니다.바이오스또는 기타 진단 소프트웨어. 컴퓨터는UEFI전용 부트로더 파티션이 있습니다.

^{마지막으로, 대부분의 컴퓨터 프로그램은 1024 = 2의 10} 제곱을 기반으로 하는 단위를 사용합니다 (프로그래머는 이진수와 2의 거듭제곱을 좋아하기 때문입니다). 따라서 1kB = 1024B, 1MB = 1048576B, 1GB = 1073741824, 1TB = 1099511627776B,...공식적으로 이러한 단위를 호출합니다.킬로바이트기본 천,테라바이트MiB 등이지만 대부분의 소프트웨어는 k 또는 kB, M 또는 MB 등만 보고합니다. 반면, 하드 드라이브 제조업체에서는 체계적으로 미터법(1000을 기준으로 한 단위)을 사용합니다. 따라서 1TB 드라이브는 931GiB 또는 0.904TiB에 불과합니다.

파일 크기 및 디스크 공간 계산의 복잡성에 대한 간략한 요약:

• 파일이 디스크에서 차지하는 공간은 차지하는 블록 수 x 각 블록 크기 + 차지하는 inode 수입니다. 1바이트 길이의 파일에는 최소 1개의 블록, 1개의 inode 및 1개의 디렉터리 항목이 필요합니다.

  그러나 파일이 다른 파일에 대한 하드 링크인 경우 추가 디렉토리 항목이 하나만 필요할 수 있습니다. 이것은 동일한 청크에 대한 또 다른 참조일 뿐입니다.

• 파일 내용의 크기입니다. 이것이 ls표시되는 것입니다.
• 사용 가능한 디스크 공간은 들어갈 수 있는 가장 큰 파일의 크기도 아니고 디스크에 들어갈 수 있는 모든 파일 내용의 크기를 합한 것도 아닙니다. 그 사이 어딘가에 있습니다. 이는 파일 수(inode 점유), 블록 크기 및 각 파일의 내용이 블록을 얼마나 잘 채우는지에 따라 달라집니다.

이는 파일 시스템의 겉모습일 뿐이며 지나치게 단순화된 것입니다. 또한 다른 파일 시스템은 다르게 작동한다는 점을 기억하십시오.

stat이 정보 중 일부를 발견하는 데 매우 도움이 됩니다. 다음은 stat 사용 방법과 그 용도에 대한 몇 가지 예입니다.http://landoflinux.com/linux_stat_command_examples.html

df일반적으로 파일 시스템이 무엇인지, 각 파일 시스템이 얼마나 꽉 차 있는지, 마운트된 위치를 확인하는 데 사용됩니다. 이는 파일 시스템 공간이 부족하고 파일 시스템 간에 콘텐츠를 이동하거나 더 큰 디스크를 구입하려는 경우 등에 유용합니다.

du각 디렉터리에서 소비하는 누적 스토리지에 대한 세부 정보를 표시합니다(Windows와 유사 windirstat). 파일 정리를 시도할 때 공간이 차지하는 위치를 찾는 데 적합합니다.

남들이 설명하는 사소한 수치적 차이를 제외하고는 유틸리티 du의 목적이 많이 다르다고 생각합니다.df

du여기서는 차이를 초래하는 다양한 상황에 대해 설명하겠습니다 df.

dfdu각 파일의 크기 정보를 이용하여 파일 시스템이 할당한 블록 수를 계산합니다 . 다양한 이유로 차이가 발생할 수 있습니다.

1. 응용 프로그램에서 아직 열려 있는 연결 해제된(삭제된) 파일입니다. 파일 정보가 손실되고 블록은 여전히 ​​할당됩니다. lsof +aL1 <filesystem>프로세스를 식별하는 데 도움이 될 것입니다. 대부분의 경우 공간을 확보하기 위해 프로세스를 종료해야 합니다(프로세스에 따라 구성을 다시 로드하는 것만으로도 충분할 때도 있습니다).

2. 마운트 지점 아래의 파일은 에 숨겨지지만 du에는 숨겨지지 않습니다 df. debugfs파일 시스템을 읽는 데 도움이 될 수 있습니다.

   $ sudo debugfs 
   debugfs 1.42.12 (29-Aug-2014)
   debugfs:  open /dev/xxx    (the desired file system  device)
   debugfs:  cd /boot
   debugfs:  ls -l 
    1966081   40755 (2)      0      0    4096 26-May-2016 16:28 .
          2   40555 (2)      0      0    4096 11-May-2016 10:43 ..
    1974291  100644 (1)      0      0       0 26-May-2016 16:28 bob   <---<<< /boot/bob is hidden by /boot fs
   

3. 스파스 파일실제보다 더 커 보이네요. 할당되지 않은 블록은 계산되지 않지만 df겉보기 파일 크기는 du.

하드 링크는 스푸핑되지 않습니다 du.