Linux 디렉토리 크기 / 블록 수의 단조 증가

8

Linux에서 (아마도 파일 시스템 블록 크기의 함수로) 디렉토리를 작성하고 디렉토리를 작성하면 stat4096의 크기를 리턴합니다. 에 의해보고 된 디렉토리 stat.

어떤 시점에서 디렉토리가 많은 파일, 디렉토리 크기 풍선으로 채워짐에 따라 (디렉토리의 내용에 대해 이야기하지 않고 디렉토리 자체를 나타내는 데 소비되는 블록에 대해 이야기합니다). 파일이 삭제되면 디렉토리 크기는 동일하게 유지됩니다.

다음은 간단한 예입니다.

[root@uxlabtest:/]$ mkdir test
[root@uxlabtest:/]$ stat test
  File: `test'
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: fd00h/64768d    Inode: 1396685     Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-07-26 14:06:04.000000000 -0400
Modify: 2011-07-26 14:06:04.000000000 -0400
Change: 2011-07-26 14:06:04.000000000 -0400

그런 다음 많은 파일을 터치하십시오.

[root@uxlabtest:/]$ for i in `seq 1 10000`; do touch /test/$i; done
[root@uxlabtest:/]$ stat test
  File: `test'
  Size: 155648          Blocks: 312        IO Block: 4096   directory
Device: fd00h/64768d    Inode: 1396685     Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-07-26 14:06:04.000000000 -0400
Modify: 2011-07-26 14:06:56.000000000 -0400
Change: 2011-07-26 14:06:56.000000000 -0400

그런 다음 파일을 삭제하십시오.

[root@uxlabtest:/]$ rm -rf /test/*
[root@uxlabtest:/]$ stat test
  File: `test'
  Size: 155648          Blocks: 312        IO Block: 4096   directory
Device: fd00h/64768d    Inode: 1396685     Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-07-26 14:07:11.000000000 -0400
Modify: 2011-07-26 14:07:12.000000000 -0400
Change: 2011-07-26 14:07:12.000000000 -0400

내 질문은 :

디렉토리의 크기 / 블록 수가 단조 증가하는 이유는 무엇입니까?
이것은 기본 파일 시스템 또는 Linux VFS의 기능입니까?
디렉토리를 삭제하고 다시 작성하지 않고도 디렉토리 크기를 줄일 수 있습니까?
보너스 포인트 :이 동작이 구현 된 커널 소스 코드를 알려주세요.

linux inode vfs

— 영원히
소스

왜 이것이 투표가 어려운지 잘 모르겠습니다. 이들은 시나리오를 복제하기 위해 주어진 명령으로 합법적이고 명확하게 표현 된 질문입니다. 이 질문에 대한 답변은 커뮤니티 지식을 만족 시키며 어딘가에 문서화 한 것이 유용합니다.

— loopforever

9

다음은 ext2 / ext3 / ext4에 해당되는 답변입니다. 다른 파일 시스템에 해당되는 경우 구현에 따라 다릅니다.

user48838이 이것에 올바르게 대답했습니다. 더 많은 파일은 더 많은 메타 데이터를 소비합니다. 이들은 4k 청크 또는 파일 시스템 작성시 정의 된 다른 크기로 할당됩니다.
예, 실제 파일 시스템의 기능 / 문제입니다
ext3 파일 시스템에서는 불가능합니다. (빈) 디렉토리를 다시 작성해야만
소스 코드는 여기 와 관련 파일에 있습니다.

그러나 당신은 운이 있습니다. 이미 삭제 한 동일한 양의 파일을 다시 만들면 디렉토리 크기는 동일하게 유지됩니다. 더 많은 파일을 추가 할 때만 증가합니다.

— mailq
소스

1

한 가지 : "e2fsck -fD"는 ext2 / 3 파일 시스템의 모든 디렉토리를 압축해야합니다. OP가 느리다고 생각하지만 파일 시스템이 오프라인 상태 여야하지만 OP가 원하는 것을 수행 할 수 있습니다. 새 디렉토리의 모든 파일을 링크하고 이전 디렉토리를 삭제하는 것보다 시간이 오래 걸립니다.

— akramer

4

표시되는 블록 증분은 파일 시스템이 파일 스토리지 및 관련 파일 관리 정보를 관리하는 방법 때문입니다. 설명 된 상황에서는 4K 씩 증가하는 것처럼 보이므로 파일 시스템에 들어가는 각 "new"/ "unique"항목은 실제 데이터 크기가 전체 4K를 채우는 지 여부에 상관없이 4K를 예약합니다. 관련 데이터가 전체 4K를 차지하는 경우 전체 관련 데이터 스트림 / 시퀀스를 저장하는 데 필요에 따라 다른 4K 블록이 예약되고 채워집니다.

파일 시스템에 의해 관리되는 "하드"대 "소프트"삭제에 따라, 삭제는 (보통 "삭제 취소"기능이 아닌) 예약 된 블록을 즉시 해제 할 수 없습니다. 일부 파일 시스템은 서로 다른 유형의 "삭제"를 구분하고 해당 스토리지 블록 관리 기능을 제공 할 수 있습니다.

스토리지 시스템에 접근하고 구현하는 방법은 파일 시스템마다 다르므로 다중 / 모듈 식 파일 시스템을 지원하는 OS에서 OS는 일반적으로 파일 시스템에 통합 할 수있는 "후크"만 제공합니다.

— 사용자
소스

1

user48838의 좋은 답변에 약간의 해설을 추가하십시오 :

디렉토리를 포함한 모든 것이 파일입니다. 모든 파일 정보를 저장하려면 공간이 필요합니다.

작은 디렉토리에 '64B used'를 표시하고 실제로 사용 된 공간의 양을 표시하는 것도 유효하지만 어쨌든 디스크에서 4K의 배수를 사용하고 있으므로 사용 된 공간의 양.

FS 디자인 관점에서 왜 사용 된 항목을 계산하는 데 어려움을 겪고 있습니까? 필요하지 않습니다. 그런 다음 구멍을 남기지 않기 위해 항목을 이동해야합니다.

삭제가 일어날 디렉토리 크기는 당신이 너무 떨어지면 수있는 블록을 확보, 관리는 어떻게해야 모든 것을 실제로 그렇게 할 수 있기 전에. 왜 몇 KB를 절약해야합니까? 어쨌든 나중에 확장해야합니다.

독자를위한 연습으로 남겨둔 이유 : / lost + found 디렉토리가 비어 있지만 16K (최소한 ext3)를 차지하는 이유를 생각해보십시오.

— MikeyB
소스