EXT3: ถ้าขนาดบล็อกเป็น 4K ทำไม ls -l แสดงขนาดไฟล์ด้านล่าง

หากคุณรัน ls -l ในไฟล์ที่มีตัวอักษรหนึ่งตัวจะมีขนาดเป็น 2B หากระบบไฟล์ของคุณอยู่ในบล็อก 4k ฉันคิดว่ามันปัดไฟล์เป็นขนาดบล็อกหรือไม่ เป็นเพราะ ls -l อ่านจำนวนไบต์จาก inode จริงหรือไม่ ในกรณีใดบ้างที่คุณถูกปัดเศษขึ้นเพื่อบล็อกคำตอบกับจำนวนไบต์ที่แท้จริงในคำตอบใน Linux 2.6 Kernel GNU utils

ฉันเดาว่าคุณมีตัวอักษรตัวหนึ่งในไฟล์ที่มีecho a > fileหรือvim fileซึ่งหมายความว่าคุณจะมีตัวอักษรนั้นและมีการขึ้นบรรทัดใหม่เพิ่มเติม (อักขระสองตัวดังนั้นสองไบต์) ls -lแสดงขนาดไฟล์เป็นไบต์ไม่ใช่บล็อก (เฉพาะเจาะจงมากขึ้น: ความยาวไฟล์):

$ echo a > testfile
$ ls -l testfile
-rw-r--r-- 1 user user 2 Apr 28 22:08 testfile
$ cat -A testfile
a$

(โปรดทราบว่าcat -Aแสดงบรรทัดใหม่เป็น$อักขระ)

ในทางตรงกันข้ามกับls -l, duจะแสดงขนาดจริงครอบครองของดิสก์:

$ du testfile
4

(ที่จริงแล้วduแสดงขนาดเป็นหน่วย 1kiB ดังนั้นนี่คือขนาด 4 × 1024 ไบต์ = 4096 ไบต์ = 4 kiB ซึ่งเป็นขนาดบล็อกของระบบไฟล์นี้)

หากต้องการlsแสดงสิ่งนี้คุณจะต้องใช้-sตัวเลือกแทน / เพิ่มเติมจาก-l:

$ ls -ls testfile
4 -rw-r--r-- 1 user user 2 Apr 28 22:08 testfile

คอลัมน์แรกคือขนาดที่จัดสรรอีกครั้งในหน่วยของ 1kiB สุดท้ายสามารถเปลี่ยนแปลงได้โดยการระบุ--block-sizeเช่น

$ ls -ls --block-size=1 testfile
4096 -rw-r--r-- 1 aw aw 2 Apr 28 22:08 testfile

ฉันคิดว่าคำตอบที่ลึกซึ้งคือต่อไปนี้:

ความยาวของไฟล์โลจิคัลและพื้นที่ว่างบนดิสก์นั้นต่างกันมาก

ตามคำตอบอื่น ๆ ที่แสดงในหลักการไฟล์ที่สร้างขึ้นด้วยสองไบต์มีความยาวสองไบต์ (แสดงโดยls -l) และครอบครอง 4 KiB (แสดงโดยduหรือls -ls)

ดู:

1& [:~/tmp] % echo -n A > test
1& [:~/tmp] % ls -l test
-rw-rw-r-- 1 romano romano 1 Apr 28 14:31 test
1& [:~/tmp] % du test
4 test

ตกลงtestมีความยาว 1 และขนาด (บนดิสก์) 4 KiB แต่:

1& [:~/tmp] % truncate -s +8191 test
1& [:~/tmp] % ls -l test
-rw-rw-r-- 1 romano romano 8192 Apr 28 14:33 test
1& [:~/tmp] % du test
4   test

(คำสั่งแรกเพิ่ม 8191 ศูนย์ไบต์test) ตอนนี้การทดสอบมีความยาว 8192 แต่ยังคงครอบครอง 4 KiB บนดิสก์ (มันมี "รู") ในนั้น (1)

ระบบไฟล์บางตัวยังสามารถกะทัดรัดไฟล์สั้น ๆ เพื่อให้พวกเขาใช้พื้นที่น้อยลงโดยการแชร์บล็อก (ดูตัวอย่างการจัดเรียงหาง ) และอื่น ๆเช่น btrfs ทำการคัดลอกเมื่อเขียนดังนั้นความสัมพันธ์ระหว่างไฟล์ความยาวโลจิคัลและพื้นที่ว่าง ดิสก์นั้นซับซ้อน

เชิงอรรถ:

(1) มันไม่ได้เป็นรูจริงๆมันเป็นตอนจบ ... แต่ก็ยังทำงานได้จนถึงตอนท้ายของตัวอย่าง

ls -lเป็นเพียงรูปแบบยาว ls -lsใช้เพื่อแสดงขนาดบล็อก

การทดสอบ

echo "1" > 1.txt

bash-3.2$ ls -l 1.txt
-rw-rw-r-- 1 ramesh ramesh 2 Apr 28 15:15 1.txt

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

bash-3.2$ ls -ls 1.txt
4 -rw-rw-r-- 1 ramesh ramesh 2 Apr 28 15:15 1.txt

4 ด้านบนแสดงขนาดบล็อกที่ใช้ นอกจากนี้เรายังสามารถตรวจสอบเดียวกันโดยใช้statคำสั่ง

bash-3.2$ stat 1.txt
  File: `1.txt'
  Size: 2               Blocks: 8          IO Block: 4096   regular file
Device: 805h/2053d      Inode: 48267720    Links: 1
Access: (0664/-rw-rw-r--)  Uid: (  505/  ramesh)   Gid: (  508/  ramesh)
Access: 2014-04-28 15:17:31.000000000 -0500
Modify: 2014-04-28 15:15:58.000000000 -0500
Change: 2014-04-28 15:15:58.000000000 -0500

ตอนนี้คำถามที่เกิดขึ้นเกี่ยวกับเหตุผลที่ls -lsรายการบล็อกขนาด 4 ในขณะที่statจอแสดงผลขนาดบล็อกเป็น 8. เหตุผลสำหรับพฤติกรรมนี้จะมีการอธิบายอย่างชัดเจนในคำตอบที่นี่

ดิสก์จำนวนมากมีขนาดเซกเตอร์ 512 ไบต์ซึ่งหมายความว่าการอ่านหรือเขียนใด ๆ บนดิสก์จะถ่ายโอนเซกเตอร์ 512 ไบต์ทั้งหมด มันค่อนข้างเป็นธรรมชาติในการออกแบบระบบไฟล์ที่เซกเตอร์ไม่แยกระหว่างไฟล์ (ซึ่งจะทำให้การออกแบบและประสิทธิภาพการทำงานแย่ลง) ดังนั้นระบบไฟล์จึงมีแนวโน้มที่จะใช้ 512 ไบต์สำหรับไฟล์ ดังนั้นยูทิลิตี้แบบดั้งเดิมเช่นlsและduระบุขนาดในหน่วยของชิ้น 512 ไบต์