☰

UNIX와 유사한 시스템/파일 시스템에서 stat()에 의해 반환된 st_blocks 필드가 512바이트 단위가 아닌 것은 무엇입니까?

tag-icon • tag-icon stat portability api
UNIX와 유사한 시스템/파일 시스템에서 stat()에 의해 반환된 st_blocks 필드가 512바이트 단위가 아닌 것은 무엇입니까?

나는 항상 /... 시스템 호출에 의해 반환된 필드가 st_blocks512바이트 단위로 표현된 파일의 디스크 사용량을 가져오는 데 사용된다고 가정합니다.stat()lstat()du

조사하다POSIX 사양, 이제 POSIX는 이에 대해 어떠한 보장도 하지 않는다는 것을 알았습니다.perl자체 stat()기능 에 대한 문서화또한 이런 가정을 하지 말라고 경고합니다.

st_blksize그럼에도 불구하고 POSIX에서 알 수 있듯이 이 블록 크기는 반환된 필드와 아무 관련이 없으므로 stat()다른 곳에서 찾아야 합니다.

GNU du또는 GNU find소스 코드를 확인해보면 HP/UX가 1024바이트 단위를 사용한다는 증거가 보입니다. GNU는 항상 여러 개의 512바이트 단위를 제공하도록 출력을 find조정하는데 -printf %b, 이것이 혼란의 원인이 될 수 있습니다.

st_blocks512바이트 단위로 표현 되지 않는 다른 Unix 계열 시스템이 아직 사용되고 있습니까 ? POSIX에서 제안한 대로 파일 시스템에 따라 달라질 수 있습니까? HP/UX NFS 공유를 마운트하면 문제가 해결될 것 같습니다.

답변1

st_blksize이를 사용된 단위에 관계없이 "최적 I/O 크기"라고 합니다 st_blocks. 물론 최적의 I/O 크기는 파일 시스템에 따라 다릅니다. 이는 fast filesystem1981/1982년 Berlekey 개발의 결과입니다. 이전에는 사용 가능한 파일 시스템 중 최적의 블록 크기가 없었습니다.

st_blocks단위로 표현하면 DEV_BSIZE실제로 HP-UX에서는 1024입니다. DEV_BSIZE플랫폼별 상수입니다. 나중에 FFS이름이 바뀌었을 때 UFS간접 블록과 관련하여 다른 동작을 갖고 이 새로운 stat()필드가 필요한 두 번째 파일 시스템이 BSD UNIX에 나타났습니다. 이전에는 du파일 시스템의 간접 블록에 대한 알고리즘만 알고 있었습니다.

dfHP-UX NFS 파일 서버 및 기타 NFS 클라이언트를 실행하는 경우 HP가 지난 15년 동안 문제를 해결했고 최신 버전의 HP에 액세스할 수 없는 경우가 아니면 HP-UX NFS 서버로부터 오류 보고서를 받게 됩니다. - UX. 내가 아는 한 다른 UNIX에는 유사한 NFS 관련 버그가 없습니다.

참고: NFSv3까지 NFS는 블록 크기를 512로 가정했으며 HP는 서버에서 NFS 보고를 변환해야 했습니다. NFSv4에서는 이러한 암시적인 가정을 하지 않지만 HP-UX는 여전히 잘못된 숫자를 보고합니다.

내가 아는 한, 다른 어떤 UNIX도 1024를 기반으로 하지 않습니다 DEV_BSIZE.

관련 정보