답변:
숫자를 쉽게 추가 할 수 있습니다. 문제는 더할 숫자가 많이 있다는 것입니다.
기본 아이디어는 n 바이트를 포함하는 파일 은 n 바이트의 디스크 공간과 일부 제어 정보 (파일의 메타 데이터 (권한, 타임 스탬프 등) 및 시스템에 필요한 정보에 대한 약간의 오버 헤드)에 약간의 비트를 사용한다는 것입니다. 파일이 저장된 위치를 찾으십시오. 그러나 많은 합병증이 있습니다.
라이브러리에서 각 파일을 일련의 책으로 생각하십시오. 작은 파일은 하나의 볼륨 만 구성하지만 큰 파일은 백과 사전과 같은 많은 볼륨으로 구성됩니다. 파일을 찾을 수 있도록 모든 볼륨을 참조하는 카드 카탈로그가 있습니다. 각 볼륨에는 덮개로 인해 약간의 오버 헤드가 있습니다. 파일이 매우 작은 경우이 오버 헤드는 상대적으로 큽니다. 또한 카드 카탈로그 자체가 어느 정도 공간을 차지합니다.
일반적인 간단한 파일 시스템에서 좀 더 기술적으로 사용하면 공간이 블록 으로 나뉩니다 . 일반적인 블록 크기는 4KiB입니다. 각 파일은 정수 블록 수를 차지합니다. 파일 크기가 블록 크기의 배수가 아닌 한 마지막 블록은 부분적으로 만 사용됩니다. 따라서 1 바이트 파일과 4096 바이트 파일은 모두 1 블록을 차지하고 4097 바이트 파일은 2 블록을 차지합니다. 당신은 이것을 관찰 할 수있는 du명령 : 당신의 파일 시스템은 4KiB 블록 크기를 가지고 있다면, du1 바이트 파일 4KiB를보고합니다.
파일이 크면 파일을 구성하는 블록 목록을 저장하기 위해 추가 블록이 필요합니다 (이것은 간접 블록입니다 .보다 정교한 파일 시스템은이를 범위 의 형태로이를 최적화 할 수 있습니다 ). 이것들은 ls -lGNU에 의해보고 된 파일 크기로 표시되지 않습니다 du --apparent-size. du크기와 반대로 디스크 사용량을보고하는 디스크가이를 설명합니다.
일부 파일 시스템은 마지막 블록에 남아있는 여유 공간을 재사용 하여 동일한 블록에 여러 파일 테일을 압축 하려고합니다 . Linux 3.8 이후 ext4 와 같은 일부 파일 시스템 은 inode에 완전히 맞는 작은 파일 (몇 바이트)에 0 블록을 사용합니다.
일반적으로 위에서 볼 수 있듯이보고 된 총 크기 du는 파일에서 사용 된 블록 또는 범위의 크기의 합입니다.
du파일이 압축 된 경우 보고 된 크기 가 더 작을 수 있습니다. 유닉스 시스템은 전통적으로 조잡한 압축 형식을 지원합니다. 파일 블록에 널 바이트 만 포함 된 경우 0 블록을 저장하는 대신 파일 시스템은 해당 블록을 모두 생략 할 수 있습니다. 이와 같이 블록이 생략 된 파일을 스파 스 파일 이라고 합니다 . 파일에 일련의 널 바이트가 포함 된 경우 스파 스 파일이 자동으로 생성되지 않으므로 응용 프로그램은 파일이 스파 스되도록 정렬해야합니다.
btrfs 및 zfs 와 같은 일부 파일 시스템 은 범용 압축을 지원 합니다 .
zfs 및 btrfs와 같은 최신 파일 시스템의 두 가지 주요 기능으로 인해 파일 크기와 디스크 사용량 간의 관계가 훨씬 더 멀어집니다 (스냅 샷 및 중복 제거).
스냅 샷 은 특정 날짜의 파일 시스템이 고정 된 상태입니다. 이 기능을 지원하는 파일 시스템에는 다른 날짜에 찍은 여러 스냅 샷이 포함될 수 있습니다. 물론이 스냅 샷은 공간을 차지합니다. 극단적으로, 파일 시스템의 활성 버전에서 모든 파일을 삭제하면 스냅 샷이 남아 있으면 파일 시스템이 비워지지 않습니다.
스냅 샷 이후 또는 두 스냅 샷 사이에서 변경되지 않은 파일 또는 블록은 스냅 샷과 활성 버전 또는 다른 스냅 샷에 동일하게 존재합니다. 이것은 copy-on-write 를 통해 구현됩니다 . 일부 경우에는 사용 가능한 공간이 부족하여 전체 파일 시스템에서 파일을 삭제하지 못할 수 있습니다. 해당 파일을 제거하면 디렉토리에 블록의 사본이 필요하고 하나의 블록까지도 더 이상 공간이 없기 때문입니다.
중복 제거 는 동일한 블록을 저장하지 않는 스토리지 최적화 기술입니다. 일반적인 데이터를 사용하여 중복을 찾는 것이 항상 노력할만한 가치는 없습니다. 모두 ZFS 및 btrfs를이 옵션 기능으로 중복 제거를 지원합니다.
du총계가 파일 크기의 합계와 다른 이유는 무엇 입니까?위에서 살펴본 것처럼 du각 파일에 대해 보고되는 크기 는 일반적으로 파일에서 사용 된 블록 또는 범위의 크기의 합입니다. 기본적으로 ls -l크기는 바이트 단위로 du나열 되지만 일부 기존 시스템에서는 KiB 또는 512 바이트 단위 (섹터)로 크기가 표시됩니다 ( du -k킬로바이트 사용 강제). 대부분의 현대적인 유닉스 지원 ls -lh과 du -h등 접미사 K, M, G를 사용하여 "사람이 읽을 수있는 '번호를 사용하는 것이 적절한 (킬로바이트 해당 MIB, 지브에 대한).
du디렉토리에서 실행할 때 디렉토리 자체를 포함하여 디렉토리 트리에있는 모든 파일의 디스크 사용량을 요약합니다 . 디렉토리에는 데이터 (파일 이름 및 파일의 메타 데이터가있는 위치에 대한 포인터)가 포함되므로 약간의 저장 공간이 필요합니다. 작은 디렉토리는 하나의 블록을 차지하고 큰 디렉토리는 더 많은 블록을 요구합니다. 디렉토리가 사용하는 저장 공간은 포함 된 파일뿐만 아니라 파일이 삽입 된 순서 및 일부 파일이 제거되는 순서 (일부 파일 시스템의 경우 디스크 공간과 성능 사이의 절충)로 인해 결정됩니다. )이지만 차이는 작습니다 (여기 및 추가 블록). 달릴 때ls -ld /some/directory디렉토리의 크기가 나열됩니다. (출력의 상단에있는 "총 NNN"행 ls -l은 관련이 없으며 KiB 또는 섹터로 표시되는 나열된 항목의 블록 단위 크기의 합계입니다.)
명심 du포함 점 파일을ls 사용자가 사용하지 않으면 표시되지 않습니다 -A또는 -a옵션을 선택합니다.
때로는 du예상 합계보다 적은보고합니다. 디렉토리 트리 내에 하드 링크 가있는 경우 발생합니다 du. 각 파일을 한 번만 계산합니다.
ZFSLinux 와 같은 일부 파일 시스템에서는 파일의 du확장 된 속성이 차지하는 전체 디스크 공간을보고하지 않습니다.
디렉토리 아래에 마운트 지점이있는 du경우 -x옵션이 제공되지 않는 한이 마운트 지점의 모든 파일도 계산합니다 . 예를 들어 루트 파일 시스템에있는 파일의 전체 크기를 원한다면 du -x /, not을 실행하십시오 du /.
파일 시스템이 비어 있지 않은 디렉토리에 마운트 된 경우 해당 디렉토리의 파일은 마운트 된 파일 시스템에 의해 숨겨집니다. 그들은 여전히 자신의 공간을 차지하지만 du찾지 못합니다.
파일이 삭제 되면 파일 자체가 아닌 디렉토리 항목 만 제거됩니다. 실제로 파일을 삭제하여 디스크 공간을 확보하려면 두 가지 조건이 필요합니다.
fuser -m또는 lsof마운트 포인트에는 파일이 삭제 된 경우에도 해당 파일 시스템에서 파일을 연 프로세스가 포함됩니다.loop장치 의 백엔드 인 경우 파일 공간을 회수하지 못할 수 있습니다 . losetup -a( root) loop는 현재 어떤 장치가 설정되어 있고 어떤 파일에 있는지 알려줍니다 . losetup -d디스크 공간을 확보 하려면 루프 장치를 (와 함께 ) 제거해야합니다.일부 파일 관리자 또는 GUI 환경에서 파일을 삭제하면 삭제되지 않은 휴지통에 파일이있을 수 있습니다. 파일을 삭제 취소 할 수있는 한 해당 공간은 여전히 사용됩니다.
df정확히 무엇입니까?일반적인 파일 시스템에는 다음이 포함됩니다.
는 첫 번째 종류 만보고합니다 du. 그것이 올 때에 df는, "사용" "사용 가능한"총 열로가는 무엇을 "사용"열에 항상 (물론 간접 포함한 블록 (사용) 파일 시스템에 따라, 그리고 사용되지 않는 블록 "은 항상있다 사용 가능 '열).
ext2 / ext3 / ext4의 파일 시스템 은 공간의 5 %를 루트 사용자에게 예약 합니다. 이것은 루트 파일 시스템에서 시스템이 가득 찼을 때 시스템이 계속 작동하도록 유지하는 데 유용합니다 (특히 로깅의 경우 시스템 관리자가 문제를 해결하는 동안 약간의 데이터를 저장하도록 함). 와 같은 데이터 파티션의 경우에도 /home거의 전체 파일 시스템이 조각화되기 때문에 예약 된 공간을 유지하는 것이 유용합니다. Linux는 파일을 쓸 때 많은 연속 블록을 미리 할당하여 조각화 (특히 하드 디스크와 같은 회전 기계 장치에서 파일 액세스 속도 저하)를 피하려고하지만 연속 블록이 많지 않으면 작동하지 않습니다. .
btrfs가 아닌 ext4 이하의 기존 파일 시스템은 파일 시스템이 생성 될 때 고정 된 수의 inode를 예약합니다 . 이는 파일 시스템의 디자인을 크게 단순화하지만 inode 수를 적절히 조정해야한다는 단점이 있습니다. inode가 너무 많으면 공간이 낭비됩니다. inode가 너무 적 으면 파일 시스템에 공간이 부족하기 전에 inode가 부족할 수 있습니다. 이 명령 df -i은 사용중인 inode 수와 사용 가능한 수를보고합니다 (개념을 적용 할 수없는 파일 시스템은 0을보고 할 수 있음).
tune2fs -lext2 / ext3 / ext4 파일 시스템이 포함 된 볼륨에서 실행 하면 사용 가능한 inode 및 블록의 총 수와 수를 포함하여 일부 통계가보고됩니다.
문제를 혼동 할 수있는 또 다른 기능은 하위 볼륨 ( btrfs 및 zfs에서 이름 데이터 집합 아래에서 지원됨 )입니다. 여러 하위 볼륨은 동일한 공간을 공유하지만 별도의 디렉토리 트리 루트가 있습니다.
파일 시스템이 네트워크 (NFS, Samba 등)를 통해 마운트되고 서버가 해당 파일 시스템의 일부를 내 보내면 (예 : 서버에 /home파일 시스템이 있고 내보내기/home/bob ) df클라이언트에서 전체 파일 시스템에 대한 데이터를 반영합니다. 클라이언트에서 내보내고 마운트 한 부분에 대해서만.
위에서 보았 듯이,보고 된 총 크기 df가 항상 파일 시스템의 모든 제어 데이터를 고려하지는 않습니다. 필요한 경우 파일 시스템 별 도구를 사용하여 파일 시스템의 정확한 크기를 얻습니다. 예를 들어, ext2 / ext3 / ext4를 사용 tune2fs -l하여 블록 크기에 블록 크기를 곱하고 곱하십시오.
파일 시스템을 만들 때 일반적으로 파일 시스템은 둘러싸는 파티션 또는 볼륨에서 사용 가능한 공간을 채 웁니다. 파일 시스템을 이동하거나 볼륨 크기를 조정할 때 파일 시스템이 더 작아 질 수 있습니다.
Linux에서는 lsblk사용 가능한 스토리지 볼륨에 대한 훌륭한 개요를 제공합니다. 추가 정보가없는 lsblk경우 전문 볼륨 관리 또는 파티셔닝 도구를 사용하여 어떤 파티션이 있는지 확인하십시오. 리눅스에서있다 lvs, vgs, pvs에 대한 LVM , fdisk기존의 PC 스타일 ( "MBR") 파티션 (뿐만 아니라 GPT 등의 최신 시스템)에 대한 gdisk대한 GPT의 분할, disklabelBSD의 디스크 라벨 (disklabel)을 위해 헤어 리눅스에서 등, cat /proc/partitions빠른 요약을 제공합니다. 일반적인 설치에는 운영 체제에서 사용하는 최소한 두 개의 파티션 또는 볼륨이 있습니다 : 파일 시스템 (때로는 그 이상)과 스왑 볼륨.
일부 컴퓨터가 포함 된 파티션이 BIOS 또는 다른 진단 소프트웨어를. UEFI 가있는 컴퓨터 에는 전용 부트 로더 파티션이 있습니다.
마지막으로, 대부분의 컴퓨터 프로그램은 1024 = 2 10의 거듭 제곱 (프로그래머는 이진법과 2의 거듭 제곱을 좋아하기 때문에)을 기반으로하는 단위를 사용 합니다. 따라서 1 kB = 1024 B, 1 MB = 1048576 B, 1 GB = 1073741824, 1 TB = 1099511627776 B,… 공식적으로 이러한 단위는 kibibyte KiB, mebibyte MiB 등 으로 알려져 있지만 대부분의 소프트웨어는 반면 M 또는 MB 등. 하드 디스크 제조업체는 체계적으로 미터법 (1000 기반 단위)을 사용합니다. 따라서 1TB 드라이브는 931GiB 또는 0.904TiB입니다.
du 않는 간접 블록 계정을. 이것이보고 한 파일 크기와의 주요 차이점입니다 ls -l.
파일 크기 및 디스크 공간 계산과 관련된 간단한 요약 정보 :
파일이 디스크에서 차지하는 공간은 각 블록의 크기와 소요되는 inode 수에 대한 블록 수의 배수입니다. 1 바이트 길이의 파일에는 최소 1 개의 블록, 1 개의 inode 및 1 개의 디렉토리 항목이 필요합니다.
그러나 파일이 다른 파일에 대한 하드 링크 인 경우 하나의 추가 디렉토리 항목 만 필요합니다. 동일한 블록 세트에 대한 또 다른 참조 일뿐입니다.
ls표시됩니다.이것은 단지 파일 시스템의 표면을 긁는 것이며 지나치게 단순화되었습니다. 또한 다른 파일 시스템이 다르게 작동한다는 것을 기억하십시오.
stat이 정보 중 일부를 발견하는 데 매우 도움이됩니다. stat 사용법과 좋은 점에 대한 몇 가지 예는 다음과 같습니다. http://landoflinux.com/linux_stat_command_examples.html
나는 원인 여기 다른 경우 설명 할 것이다 du상이한을 df.
df파일 시스템 할당 블록 수를 계산하고 du각 파일의 크기 정보를 사용하십시오. 차이점은 여러 가지 원인이있을 수 있습니다.
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
df일반적으로 파일 시스템이 무엇인지, 각 시스템이 얼마나 꽉 찼는 지, 마운트 된 위치를 확인하는 데 사용됩니다. 파일 시스템의 공간이 부족하고 파일 시스템 사이를 이동하거나 더 큰 디스크 등을 구매하려는 경우에 매우 유용합니다.
du각 디렉토리가 소비하는 누적 스토리지 양에 대한 세부 정보를 표시합니다 ( windirstatWindows에서 와 같이 정렬 됨 ). 파일 정리를 시도 할 때 공간을 차지하는 곳을 찾는 데 좋습니다.
다른 사람들이 설명 한 작은 숫자 차이 외에도 유틸리티 du와 df유틸리티는 매우 다른 용도로 사용됩니다.
tune2fs는 파일 시스템을 포함하는 블록 장치에 대한 읽기 액세스 권한이 필요합니다. 일반적으로 모든 파일의 내용을 읽을 수 있기 때문에 루트가 필요합니다.