☰

`ls -s` "0"을 인쇄할 때

tag-icon • tag-icon filesystems shell-script ls compatibility
`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
  • 솔라리스의 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

답변1

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

귀하의 질문에 : 만약인주테스트 결과를 보여주기 위해 댓글을 남겨주세요. 결과를 설명하기 위해 ls -s실제 크기(바이트)가 아닌 파일 시스템에 할당된 블록 수를 보고하는 상태입니다. 분명히 일부 파일 시스템 구현에서는 inode에 NULL 포인터를 저장하는 대신 데이터를 저장할 필요가 없더라도 블록을 할당합니다.

이에 대한 설명은 성능과 관련이 있을 수 있습니다. 비어 있는 빈 파일을 생성하는 것은 일반적인 처리의 예외입니다(내가 본 가장 일반적인 용도는 파일의 존재가 소프트웨어의 일부 상태를 나타내는 상태 파일을 생성하는 것입니다).

그러나 일반적으로 생성된 파일은 일부 데이터를 매우 빠르게 가져오므로 특정 파일 시스템 설계자는 파일이 생성되는 즉시 데이터 블록을 할당하여 첫 번째 데이터가 도착할 때 작업이 이미 완료되도록 하는 것이 가치 있다고 생각했을 수 있습니다.

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

편집하다:

또 다른 이유가 떠오릅니다. 값이 0보다 큰 파일 시스템은 다음과 같습니다.ZFS, RAID+LVM+FS 구현 및정부 재무장관, 클러스터된 파일 시스템. 둘 다 inode에 저장되지 않은 파일 무결성을 유지하기 위해 메타데이터를 저장해야 할 수도 있습니다. ls -s이 메타데이터에 할당된 데이터 블록 내의 개수일 수 있습니다 .

답변2

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

GFS가 동기화/잠금 데이터를 저장해야 하므로 다른 0이 아닌 결과가 발생하는 것 같습니다.

답변3

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, 그것이 작동하는지 증명할 책임은 그들에게 있어야 합니다.

관련 정보