ext4 사용 공간(-m 옵션 아님, 파일 삭제 안 함)

ext4 사용 공간(-m 옵션 아님, 파일 삭제 안 함)

ext4가 사용된 공간을 보고하는 방식에 대해 약간 혼란스럽습니다. 새로운 Debian wheezy(테스트) 설치에서 du. OS(Debian squeeze)를 네트워크 부팅하면 SSD에서 사용되는 추가 공간이 180MB만 표시됩니다. 로그는 128MB이므로 그 이상의 추가 용량은 없습니다.

df루트 디렉터리나 삭제된 파일용으로 예약되지 않은 경우 보고된 추가 사용 공간은 무엇입니까? Google을 사용하는 이유는 주로 제가 배제한 일반적인 이유 때문입니다. 동일한 파일 시스템의 숫자가 다른 운영 체제에 설치되면 왜 달라지나요? 재설치를 통해 테스트한 결과 추가 사용량은 다시 설치 시 약 1GB, 네트워크 부팅 및 해당 SSD를 마운트할 때 180MB였습니다.

XFS 및 btrfs에서 보고된 추가 사용량은 무시할 만한 것으로 보입니다. 파일 시스템에 약간의 오버헤드가 필요하다는 것을 알고 있지만, 그 오버헤드가 실제 사용량과 혼합되면 불편할 수 있습니다.

아래는 자세한 출력입니다.

df

$ df -m on wheezy
Filesystem              1M-blocks  Used Available Use% Mounted on
rootfs                      57132  1567     52703   3% /
udev                         7899     0      7899   0% /dev
tmpfs                        1581     1      1581   1% /run
/dev/mapper/ssd-kvmhost     57132  1567     52703   3% /
tmpfs                           5     0         5   0% /run/lock
tmpfs                        3162     0      3162   0% /tmp
tmpfs                        3162     0      3162   0% /run/shm

$ du -sm /
592     /

tune2fsInode 수는 3670016이고 크기는 256으로, 사용된 공간의 거의 모든 부분을 설명합니다. inode가 정적으로 예약되어 있기 때문에 왜 크기에서 빼지 않는지 이해할 수 없습니다. 공간으로 계산하고 항상 사용된 것으로 계산하는 것은 별 의미가 없습니다.

다음은 네트워크 부팅 데비안 squeeze에서 동일한 파일 시스템의 출력입니다:

aufs                      7905        46      7859   1% /
tmpfs                     7905         0      7905   0% /lib/init/rw
udev                      7900         1      7900   1% /dev
tmpfs                     7905         1      7905   1% /dev/shm
172.17.172.127:/storage/private/tftp/debian-live-6.0.3-amd64-lxde-desktop
                         24737     17448      7289  71% /live/image
tmpfs                     7905        46      7859   1% /live/cow
tmpfs                     7905         0      7905   0% /live
tmpfs                     7905         1      7905   1% /tmp
/dev/mapper/ssd-kvmhost
                         56337       772     52703   2% /mnt

확인하려면 네트워크 부팅 OS에서 du -sm /을 사용하세요.

592     /

어쩌면 오래된 커널은 정적으로 예약된 inode 공간을 여유 공간으로 현명하게 처리하지 않기 때문에 사용된 것으로 표시할 필요가 없을 수도 있습니다. 크기와 사용공간의 차이는 795MB로, 아이노드가 필요로 하는 공간의 거의 전부이다. 그렇다면 180MB는 무엇입니까? 이것도 정적이라면 Size에서 빼는 것이 최선의 선택이 아닐까요? 그런 다음 df다른 파일 시스템처럼 실제로 실제 사용량을 보여줄 수 있습니다.

내 파일 시스템에 정적 양의 오버헤드가 필요한 경우 동일한 양의 절대 공간에 대해 다른 파일 시스템보다 적은 여유 공간만 제공하는 것 같습니다. df는 이것을 반영해서는 안되며 얼마나 많은지 보여주어야 합니다.사용 가능한 공간내가 그것을 사용했나요?

답변1

ext[234]는 기본적으로 128MB 블록 그룹당 8192개의 inode를 예약하여 그룹당 2MB를 차지하며 이는 60GB 파일 시스템의 경우 1GB에 가깝습니다. 다른 시스템에 드라이브를 설치해도 차이가 없어야 합니다. 커널이 헐떡거림과 압착 사이의 공간 사용을 보고하는 방식을 변경한 것 같지만, 이것이 의도적으로 수행되었음을 나타내는 커밋을 찾지 못했습니다.

답변2

df 및 du의 출력을 제공하면 질문에 대한 답변이 더 쉬워집니다.

근데 비슷한 것 같아 df는 du보다 20G 더 많은 디스크 공간을 사용했다고 말했습니다. 왜?

기본적으로 파일 시스템은 자체 메타데이터, 즉 파일 자체가 아니라 파일, 이름, 권한, 디스크에서의 위치 등을 추적하기 위해 특정 디스크를 사용합니다.

위에 링크한 답변에서 알 수 있듯이 달리면 tune2fs -l <device name>더 많은 정보가 표시됩니다. 특히, inode countx는 다음과 같은 차이 에 inode size가까워야 합니다 .dfdu

이전 답변에 따르면 내 시스템의 루트 파티션은 inode용 디스크의 약 1.77%를 사용합니다. 60GB * 0.0177 ~= 1GB.

mount180MB 숫자가 잘못된 것 같지만 자세한 내용(예: 네트워크 부팅 시스템의 출력)이 없으면 확신할 수 없습니다. 예를 들어 다음과 같은 이유 때문일 수 있습니다.minixdf/bsddf설치 옵션.

관련 정보