Linux에서 (아마도 파일 시스템 블록 크기의 함수로) 디렉토리를 작성하고 디렉토리를 작성하면 stat
4096의 크기를 리턴합니다. 에 의해보고 된 디렉토리 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의 기능입니까?
- 디렉토리를 삭제하고 다시 작성하지 않고도 디렉토리 크기를 줄일 수 있습니까?
- 보너스 포인트 :이 동작이 구현 된 커널 소스 코드를 알려주세요.
답변
다음은 ext2 / ext3 / ext4에 해당되는 답변입니다. 다른 파일 시스템에 해당되는 경우 구현에 따라 다릅니다.
- user48838이 이것에 올바르게 대답했습니다. 더 많은 파일은 더 많은 메타 데이터를 소비합니다. 이들은 4k 청크 또는 파일 시스템 작성시 정의 된 다른 크기로 할당됩니다.
- 예, 실제 파일 시스템의 기능 / 문제입니다
- ext3 파일 시스템에서는 불가능합니다. (빈) 디렉토리를 다시 작성해야만
- 소스 코드는 여기 와 관련 파일에 있습니다.
그러나 당신은 운이 있습니다. 이미 삭제 한 동일한 양의 파일을 다시 만들면 디렉토리 크기는 동일하게 유지됩니다. 더 많은 파일을 추가 할 때만 증가합니다.
답변
표시되는 블록 증분은 파일 시스템이 파일 스토리지 및 관련 파일 관리 정보를 관리하는 방법 때문입니다. 설명 된 상황에서는 4K 씩 증가하는 것처럼 보이므로 파일 시스템에 들어가는 각 “new”/ “unique”항목은 실제 데이터 크기가 전체 4K를 채우는 지 여부에 상관없이 4K를 예약합니다. 관련 데이터가 전체 4K를 차지하는 경우 전체 관련 데이터 스트림 / 시퀀스를 저장하는 데 필요에 따라 다른 4K 블록이 예약되고 채워집니다.
파일 시스템에 의해 관리되는 “하드”대 “소프트”삭제에 따라, 삭제는 (보통 “삭제 취소”기능이 아닌) 예약 된 블록을 즉시 해제 할 수 없습니다. 일부 파일 시스템은 서로 다른 유형의 “삭제”를 구분하고 해당 스토리지 블록 관리 기능을 제공 할 수 있습니다.
스토리지 시스템에 접근하고 구현하는 방법은 파일 시스템마다 다르므로 다중 / 모듈 식 파일 시스템을 지원하는 OS에서 OS는 일반적으로 파일 시스템에 통합 할 수있는 “후크”만 제공합니다.
답변
user48838의 좋은 답변에 약간의 해설을 추가하십시오 :
디렉토리를 포함한 모든 것이 파일입니다. 모든 파일 정보를 저장하려면 공간이 필요합니다.
작은 디렉토리에 ’64B used’를 표시하고 실제로 사용 된 공간의 양을 표시하는 것도 유효하지만 어쨌든 디스크에서 4K의 배수를 사용하고 있으므로 사용 된 공간의 양.
FS 디자인 관점에서 왜 사용 된 항목을 계산하는 데 어려움을 겪고 있습니까? 필요하지 않습니다. 그런 다음 구멍을 남기지 않기 위해 항목을 이동해야합니다.
삭제가 일어날 디렉토리 크기는 당신이 너무 떨어지면 수있는 블록을 확보, 관리는 어떻게해야 모든 것을 실제로 그렇게 할 수 있기 전에. 왜 몇 KB를 절약해야합니까? 어쨌든 나중에 확장해야합니다.
독자를위한 연습으로 남겨둔 이유 : / lost + found 디렉토리가 비어 있지만 16K (최소한 ext3)를 차지하는 이유를 생각해보십시오.