다음과 같은 결과가 나타나는 이유를 알 수 없습니다.
ls -l
주어진 파일 (HISTORY)의 크기가 “581944”라고 알려줍니다.
$ ls -l HISTORY
-rw-rw-r-- 1 waldyrious waldyrious 581944 Feb 22 10:59 HISTORY
ls -s
“572”라고 말합니다.
$ ls -s HISTORY
572 HISTORY
분명히 값이 비슷한 척도를 사용해야합니다. 먼저 --block-size 1
in 을 사용 ls -l
하면 이전과 동일한 결과를 얻을 수 있음을 확인합니다 .
$ ls -l --block-size 1 HISTORY
-rw-rw-r-- 1 waldyrious waldyrious 581944 Feb 22 10:59 HISTORY
그런 다음 ls -s
동일한 스케일로 값을 얻기 위해 동일하게 수행합니다 .
$ ls -s --block-size 1 HISTORY
585728 HISTORY
다른 결과! 581944 ≠ 585728 .
를 사용하여 다른 방법으로 비슷한 값을 생성하려고 시도했지만 다음과 -k
같이 나타납니다.
$ ls -lk HISTORY
-rw-rw-r-- 1 waldyrious waldyrious 569 Feb 22 10:59 HISTORY
$ ls -sk HISTORY
572 HISTORY
다시, 다른 결과, 569 ≠ 572 .
–si를 지정하여 두 옵션이 모두 동일한 스케일을 사용하고 있는지 확인했습니다.
$ ls -lk --si HISTORY
-rw-rw-r-- 1 waldyrious waldyrious 582k Feb 22 10:59 HISTORY
$ ls -sk --si HISTORY
586k HISTORY
… 다시 다른 값 : 582k ≠ 586k .
나는 웹 검색 시도하지만, 관련 같았다 내가 찾을 수있는 유일한 방법이었다 이 :
일부 파일에는 “구멍”이 있으므로
ls -s
(…)로 표시된 사용량이로 표시된 파일 크기보다 작습니다ls -l
. “
(내 결과에서 반대의 경우가 발생 ls -s
합니다 ls -l
.
한편 이 페이지 는
유닉스 파일 구멍을 감지하는 우아한 방법은 없습니다.
이 불일치를 어떻게 처리 할 수 있습니까? 이 값 중 올바른 것으로 간주 될 수있는 것은 무엇입니까? 이것은 아마도 버그 일 수 ls
있습니까?
답변
짧은 답변:
ls -l
파일 크기를 제공합니다 (= 포함 된 데이터 양).ls -s --block-size 1
파일 시스템의 파일 크기를 제공합니다
두 개의 파일을 만들어 봅시다 :
스파 스 파일 (128)의 길이를 바이트 (스파 스 파일은 빈 블록을 포함하는 파일 참조입니다 스파 스 파일 ) :
# truncate -s 128 f_zeroes.img
# hexdump -vC f_zeroes.img
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000080
128 바이트 크기의 임의 데이터가있는 다른 파일 :
# dd if=/dev/urandom of=f_random.img bs=1 count=128
# hexdump -vC f_random.img
00000000 bc 82 9c 40 04 e3 0c 23 e6 76 79 2f 95 d4 0e 45 |...@...#.vy/...E|
00000010 19 c6 53 fc 65 83 f8 58 0a f7 0e 8f d6 d6 f8 b5 |..S.e..X........|
00000020 6c cf 1b 60 cb ef 06 c6 d0 99 c6 16 3f d3 95 02 |l..`........?...|
00000030 85 1e b7 80 27 93 27 92 d0 52 e8 72 54 25 4d 90 |....'.'..R.rT%M.|
00000040 11 59 a2 d9 0f 79 aa 23 2d 44 3d dd 8d 17 d9 36 |.Y...y.#-D=....6|
00000050 f5 ae 07 a8 c1 b4 cb e1 49 9e bc 62 1b 4f 17 53 |........I..b.O.S|
00000060 95 13 5a 1c 2a 7e 55 b9 69 a5 50 06 98 e7 71 83 |..Z.*~U.i.P...q.|
00000070 5a d0 82 ee 0b b3 91 82 ca 1d d0 ec 24 43 10 5d |Z...........$C.]|
00000080
따라서 16 진수 표현에서 볼 수 있듯이 내용은 상당히 다르지만 두 파일 의 데이터 양이 동일 합니다.
이제 디렉토리를 보자.
# ls -ls --block-size 1 f_*
1024 -rw-r--r-- 1 user user 128 Mar 18 15:34 f_random.img
0 -rw-r--r-- 1 user user 128 Mar 18 15:32 f_zeroes.img
^ ^
| |
Amount which the Actual file size
files takes on the fs
첫 번째 값은 -s --block-size 1
옵션 으로 제공되며 파일 시스템의 파일이 사용하는 공간 입니다.
보시다시피, 파일 시스템 ( ext3
이 경우)은 영 (0) 만 포함한다는 것을 인식 할 수있을 정도로 똑똑하기 때문에 스파 스 파일은 공간을 차지하지 않습니다. 또한 임의 데이터가있는 파일은 디스크에서 1024 바이트를 차지합니다!
값은 기본 파일 시스템이 파일을 처리하는 방법 (블록 크기, 스파 스 파일 기능 등)에 따라 다릅니다.
그것이 – 여섯 번째 열에서 당신이 그것을 읽을 것이다 경우 파일의 크기는 파일이 포함 된 데이터의 양이 그것입니다 두 파일 모두 128 바이트!
답변
ls -s
항상 할당 단위의 배수 인 파일 의 할당 된 크기를 알려줍니다 . ls -l
실제 크기를 알려줍니다. 테스트하는 쉬운 방법 :
$ echo 1 > sizeTest
$ ls -l --block-size 1 sizeTest
-rw-rw-r-- 1 g g 2 Mär 18 15:18 sizeTest
$ ls -s --block-size 1 sizeTest
4096 sizeTest