`ls -s`는 언제“0”을 인쇄합니까?

물론 파일이 비어 있는지 테스트하는 표준 방법은입니다 test -s FILE. 그러나 클라이언트 중 하나가 다음과 같은 테스트가 포함 된 스크립트를 받았습니다.

RETVAL=`ls -s ./log/cr_trig.log | awk '{print $1}'`
if test $RETVAL -ne 0
then
    echo "Badness: Log not empty"
    exit 25
fi

공급 업체의 테스트를 거친 두 환경에서 작동한다고 주장하면서 말할 필요도 없습니다.

그래서 궁금했다. 빈 파일 은 언제 ls -s인쇄 0합니까?

이것은 지금까지 나의 발견입니다.

• Linux의 GFS : 4
• Linux의 ext4 : 0
• Solaris의 ZFS : 1
• Solaris의 UFS : 0
• AIX의 jfs : 0
• HP-UX의 VxFS : 0
• HP-UX의 HFS : 0
• Mac OS X의 HFS : 0

아직 네트워크 파일 시스템을 조사하지 않았습니다.

질문 : 다른 사람들에게 스크립트가 잘못되었다는 것을 어떻게 우아하게 설명 할 수 있습니까? 있습니까?

제 생각에는 "올바른"버전은 다음과 같습니다.

if test ! -s ./log/cr_trig.log
then
    echo "Badness: Log not empty"
    exit 25
fi

매우 흥미로운 발견. ls -s파일이 비어 있는지 여부를 확인하는 데 사용한 적이 없지만 0빈 파일도 보고한다고 가정했을 것 입니다.

귀하의 질문에 : 매트가 이미 언급 했듯이 테스트 결과를 보여주십시오. 결과를 설명하기 위해 ls -s실제 크기 (바이트)가 아니라 파일 시스템에 할당 된 블록의 양 을 보고합니다. 분명히 일부 파일 시스템 구현은 inode에 NULL 포인터 만 저장하는 대신 데이터를 저장할 필요가없는 경우에도 블록을 할당합니다.

이에 대한 설명은 성능과 관련이있을 수 있습니다. 비어있는 상태로 유지되는 빈 파일을 만드는 것은 정상적인 처리를위한 예외입니다 (파일의 존재가 소프트웨어의 특정 상태를 나타내는 상태 파일을 만드는 것이 가장 일반적입니다).

그러나 일반적으로 생성 된 파일은 일부 데이터를 곧 가져 오므로 특정 FS의 설계자는 파일 생성시 데이터 블록을 즉시 할당하기 위해 비용을 지불한다고 가정했을 수 있으므로 첫 번째 데이터가 도착하면이 작업이 이미 완료되었습니다.

두 번째 이유는 파일에 과거에 지워진 데이터가 포함되어 있기 때문일 수 있습니다. 마지막 데이터 블록을 해제하는 대신 동일한 파일에서 재사용 할 수 있도록 해당 데이터 블록을 유지하는 것이 좋습니다.

편집하다:

또 다른 이유는 다음과 같습니다.> 0보다 큰 값을 찾은 파일 시스템 은 RAID + LVM + FS 구현 인 ZFS 이고 클러스터 파일 시스템 인 GFS 입니다. 둘 다 inode에 저장되지 않은 파일 무결성을 유지하기 위해 메타 데이터를 저장해야 할 수도 있습니다. ls -s이 메타 데이터에 할당 된 데이터 블록의 개수 일 수 있습니다 .

대부분의 다른 파일 시스템과 달리 ZFS는 정적 배열의 inode를 미리 할당하지 않습니다. 그런 다음 ZFS에서 빈 파일을 만들면에서보고 한 새 데이터 블록이 사용됩니다 ls -s.

GFS가 동기화 / 잠금 데이터를 저장하여 다른 0이 아닌 결과를 가져와야한다고 생각합니다.

ls -s 디렉토리 항목에 직접 저장된 내용은 포함하지 않고 파일에 할당 된 블록 수를보고합니다.

대부분의 경우 블록 수는 바이트 수를 블록 크기 (바이트 단위)로 나눈 값입니다.

블록 수는 스파 스 파일의 수보다 적을 수 있습니다 . 예를 들어, 대부분의 파일 시스템에서 0 블록에 걸쳐 8192 바이트 파일이 생성됩니다.

$ perl -e 'truncate STDOUT, 8192' >a
$ ls -l a
-rw-r--r-- 1 gilles gilles 8192 Nov  1 21:32 a
$ ls -s a
0 a

반대로, 파일 시스템이 파일에 대한 블록을 미리 할당하거나 블록을 사용하여 메타 데이터를 저장하는 경우 블록 수가 더 많아 질 수 있습니다. Zfs가 제공하는 많은 기능과 큰 파일 시스템에 대한 방향을 고려할 때 Zfs가 파일 크기와 블록 수 사이에 명백하지 않은 대응 관계를 가지고 있다는 사실은 놀랄 일이 아닙니다. 세부 사항을 모르지만 블록 수는 파일 크기뿐만 아니라 기록에도 달려 있습니다 (더 큰 파일을 자른 결과 빈 파일에 둘 이상의 블록이있을 수 있음).

왜 ls -s잘못된 지 설명하기 위해 : 파일의 크기를 계산하지 않고 파일 시스템에 따라 다릅니다. 파일이 처음에 비어 있는지 여부를 결정하는 매우 간접적 인 방법으로 외부 도구 ( ls)와 일부 구문 분석이 필요합니다. 대신 test -s구문 분석이 필요하지 않고 요청 된 내용을 정확하게 수행하는을 사용해야합니다. 그들이 그것이 ls -s파일이 비어 있는지 테스트하는 좋은 방법 이라고 생각한다면 , 그것이 작동한다는 것을 정당화하기 위해 책임을 져야합니다.