18개의 파일이 있는 디렉토리가 있는데 stat
다른 도구에서는 그 크기를 0
.
$ \stat $PWD
File: `/home/users/gholl/checkouts_local/FCDR_HIRS/FCDR_HIRS/analysis'
Size: 0 Blocks: 0 IO Block: 524288 directory
Device: 14h/20d Inode: 62487444829821592 Links: 1
Access: (0755/drwxr-xr-x) Uid: (35063/ gholl) Gid: (26030/ users)
Access: 2018-04-09 11:38:43.574427000 +0100
Modify: 2018-04-09 11:38:43.574427000 +0100
Change: 2018-04-09 11:38:43.575000000 +0100
~/checkouts_local/FCDR_HIRS/FCDR_HIRS/analysis$ \ls -1 | wc -l
18
$ mount | grep homeusers
172.26.72.131:/homeusers on /home/users type nfs (rw,tcp,hard,intr,timeo=50,addr=172.26.72.131)
시스템은 Red Hat Enterprise Linux Server 버전 6.9(San Diego)입니다. 에 따르면 df -T
파일 시스템 유형은 다음과 같습니다 nfs
.
$ df -hT .
Filesystem Type Size Used Avail Use% Mounted on
172.26.72.131:/homeusers
nfs 200T 3.5T 197T 2% /home/users
디렉토리의 크기는 파일의 메타데이터를 저장하기 때문에 그 안에 있는 파일 수와 관련이 있다고 생각합니다. 그렇다면 비어 있지 않은 디렉토리에 대해 어떻게 0이 될 수 있습니까?
참고: 서버에 대한 액세스 권한이나 수퍼유저 권한이 없으므로 서버 측에서 무슨 일이 일어나고 있는지 조사할 수 없습니다.
답변1
이는 NFS 서버의 기본 파일 시스템에 따라 다릅니다. 궁극적으로 이는 POSIX 의미의 다소 이상하고 알려지지 않은 비트로 귀결됩니다. 즉, st_blocks
반환된 필드에는 stat()
다음과 같이 할당된 블록이 포함되지 않습니다.메타데이터, 다음과 같이 할당된 블록만데이터.
이러한 차이점은 UNIX 시스템의 표준 파일 시스템이 정적으로 할당된 inode 테이블을 사용한다는 사실에서 비롯됩니다. 즉, 각 파일 시스템 개체는 메타데이터에 대해 고정된 양의 공간을 사용합니다. 따라서 파일 크기에서 해당 공간을 계산하는 것에 대해 걱정할 필요가 없습니다. , 파일의 전체 공간 사용량에 기여하지 않기 때문입니다(inode 테이블이 정적으로 할당되었기 때문에 이 공간은 이미 예약되어 있습니다). 이러한 파일 시스템에서는 디렉터리 항목이 메타데이터로 저장되지 않고 대신 주요 부분에 정기적인 간격으로 저장됩니다. 할당된 블록 파일 시스템(IOW, 디렉터리 항목은 메타데이터가 아닌 파일 내용으로 처리됨). 이는 이전 UNIX 시스템의 대부분 디렉터리 크기가 4kB의 배수인 이유입니다. 이는 대부분의 UNIX 파일 시스템 크기의 블록 크기이기 때문입니다. 이것이 바로 stat()
이를 사용하는 도구가 메타데이터를 고려하지 않고 파일 크기를 보고하는 이유입니다.
그러나 많은 최신 파일 시스템에서는 상황이 상당히 다릅니다. 메타데이터 공간은 고정 크기 항목의 정적 테이블이 아닌 동적으로 할당되며 디렉터리 항목은 메타데이터로 처리됩니다. 따라서 특정 시스템 및 파일 시스템에 따라 디렉토리의 겉보기 크기는 0으로 나타날 수도 있고, 디스크 사용량은 0(또는 stat
보고된 대로 du
)이지만 보고된 대로 겉보기 크기는 더 작은 것처럼 보일 수도 있습니다 ls
. BTRFS는 두 번째 범주에 속하는 파일 시스템의 좋은 예입니다. 디렉터리의 겉보기 크기는 디렉터리에 있는 항목 수와 해당 이름의 길이에 따라 달라지며, 보고된 디스크 크기는 다음과 같습니다 stat()
. 항상 0입니다.