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

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

ext4 보고서가 공간을 사용하는 방식에 대해 약간 의아해합니다. 새로운 Debian wheezy(테스트) 설치에서 du. 그런 다음 해당 컴퓨터를 네트워크 부팅하고 SSD를 마운트했습니다. 네트워크 부팅 OS(Debian squeeze)는 SSD에서 사용된 추가 공간이 180MB만 표시됩니다. 저널은 128MB이므로 더 이상 그 이상으로 더 이상 추가할 수 없습니다.

df루트 또는 삭제된 파일용으로 예약된 공간이 아닌 경우 에서 보고한 추가 사용 공간은 무엇입니까 ? Google을 사용하면 대부분 제가 배제한 일반적인 원인이 발생합니다. 그리고 다른 운영 체제에 마운트될 때 동일한 파일 시스템에서 그 양이 왜 다른가요? 다시 설치하여 테스트한 결과 추가 사용량은 wheezy 설치에서 다시 ~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가 정적으로 예약되어 있기 때문에 이것이 Size에서 차감되지 않는 이유를 이해할 수 없습니다. 공간으로 계산하고 항상 사용된 것으로 계산하는 것은 별 의미가 없습니다.

다음은 동일한 파일 시스템에 대한 네트워크 부팅 Debian 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이며, 이는 inode에 필요한 거의 모든 공간입니다. 그렇다면 180MB는 무엇입니까? 그것도 정적이라면 Size에서 이를 빼는 것이 최적이 아닐까요? 그런 다음 df실제로 다른 파일 시스템처럼 실제 사용법을 보여줄 수 있습니다.

내가 보기에 내 파일 시스템에 정적 양의 오버헤드가 필요한 경우 동일한 양의 절대 공간에 대해 다른 파일 시스템보다 사용 가능한 공간이 적습니다. 그것을 반영해서는 안되며, 또한사용 가능한 공간내가 사용했나요?

답변1

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

답변2

df 및 du의 출력을 제공하면 귀하의 질문에 대답하기가 더 쉬울 것입니다.

하지만 정말 그럴 것 같아 df는 du보다 20G 더 많은 디스크 공간을 사용한다고 말합니다. 왜?

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

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

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

180MB 수치가 잘못된 것 같지만 mount네트워크 부팅 시스템의 출력과 같은 자세한 내용이 없으면 확신할 수 없습니다. 예를 들어, 아마도 다음과 같은 이유 때문일 수 있습니다.minixdf/bsddf마운트 옵션.

관련 정보