เหตุใด ls -l เอาต์พุตจึงมีขนาดแตกต่างจาก ls -s


38

ฉันไม่สามารถทราบสาเหตุที่ฉันได้รับผลลัพธ์ต่อไปนี้:

ls -l บอกขนาดของไฟล์ที่กำหนด (ประวัติ) คือ "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ใน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

ผลลัพธ์ที่แตกต่าง! 581,944 ≠ 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ไม่เล็กลง)

ในขณะเดียวกันหน้านี้บอกว่า

ไม่มีวิธีที่สง่างามในการตรวจจับหลุมไฟล์ Unix

ดังนั้นฉันจะจัดการกับความคลาดเคลื่อนนี้ได้อย่างไร ค่าใดที่พิจารณาว่าถูกต้อง นี่อาจเป็นข้อผิดพลาดlsหรือไม่?

คำตอบ:


47

คำตอบสั้น ๆ :

  • 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

ดังนั้นอย่างที่คุณเห็นในการแสดงเลขฐานสิบหกทั้งสองไฟล์มีจำนวนข้อมูลเท่ากันแม้ว่าเนื้อหาจะแตกต่างกันมาก

ตอนนี้ให้เราดูที่ไดเรกทอรี:

# 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ตัวเลือกมันเป็นจำนวนของพื้นที่ที่ใช้โดยไฟล์บนระบบไฟล์

อย่างที่คุณเห็นไฟล์ sparse ใช้พื้นที่เป็นศูนย์เนื่องจากระบบไฟล์ ( ext3ในกรณีนี้) ฉลาดพอที่จะรับรู้ว่ามันมีเฉพาะเลขศูนย์ นอกจากนี้ไฟล์ที่มีข้อมูลแบบสุ่มจะใช้เวลามากถึง 1024 ไบต์บนดิสก์!

ค่าขึ้นอยู่กับวิธีที่ระบบไฟล์พื้นฐานปฏิบัติกับไฟล์ (ขนาดบล็อกความสามารถในการกระจายไฟล์, ... )

ในคอลัมน์ที่หกคือขนาดของไฟล์ถ้าคุณจะอ่านมันคือจำนวนข้อมูลที่ไฟล์มีและมันคือ128 ไบต์สำหรับไฟล์ทั้งสอง!


1
สันนิษฐานได้ว่าแม้ไฟล์เปล่าหรือไฟล์ที่เต็มไปด้วยค่า Null จะใช้พื้นที่ในตารางการจัดสรรไฟล์ที่ไหนสักแห่ง? ทำไมไม่ls -sนับเช่นนั้น
Flimm

2
ข้อมูลเมตาเกี่ยวกับไฟล์ถูกเก็บใน inodes ระบบไฟล์แต่ละระบบมีจำนวนไอโหนดที่ จำกัด ที่สามารถใช้ได้ หากต้องการดูจำนวนของ inode ที่ว่างในระบบไฟล์และขนาดของมัน: sudo tune2fs -l /dev/sdaX|grep Inodeหรือdf -iสำหรับพาร์ติชันทั้งหมด
phoibos

1
ฉันเพิ่งค้นพบที่น่าสนใจทางที่ไม่เทียมในการตรวจสอบนี้: แฟ้ม .part ฝนตกหนักดูเหมือนจะเป็นตัวอย่างที่ดีของไฟล์ที่มีหลุม: ทำให้ผมยกตัวอย่างเช่นls -lsh ~/Downloads/torrents 92K -rw-r--r-- 1 waldir waldir 350M Sep 15 2012 video.avi.partนั่นคือ 92K ที่ส่งคืนโดยตัวเลือก -s เป็นพื้นที่จริงที่ไฟล์ใช้ระบบไฟล์ฉลาดและ 350M ส่งคืนโดยตัวเลือก -l คือขนาดเต็มไฟล์ที่จะมีหากดาวน์โหลดเสร็จสมบูรณ์ (เช่น ถ้าไบต์ทั้งหมดตั้งแต่ต้นจนจบไม่เป็นศูนย์) ดูlists.freebsd.org/pipermail/freebsd-questions/2012-June/ …
waldyrious

14

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
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.