ขนาดพาร์ติชัน ext4 / ความแตกต่างของพื้นที่ว่าง


14

ขณะที่สร้างพาร์ติชั่นสำรองข้อมูล 250GiB ฉันได้สังเกตเห็นความแตกต่างมากมายระหว่างขนาดพาร์ติชันที่รายงานและเนื้อที่ว่างใน Nautilus, gParted, df, tune2fs เป็นต้น

ตอนแรกฉันคิดว่ามันเป็นความสับสนของ GiB / GB มันไม่ได้

จากนั้นฉันคิดว่ามันอาจเป็นบล็อกสำรองของ ext4 มันไม่ได้

ฉันงงอย่างสมบูรณ์ นี่คือภาพบางส่วน นี่คือขั้นตอน:

  • ก่อน NTFS 524288000 เซกเตอร์ x 512 ไบต์ / เซกเตอร์ = 268435456000 ไบต์ = 268.4 GB = 250 GiB

ป้อนคำอธิบายรูปภาพที่นี่ ป้อนคำอธิบายรูปภาพที่นี่

Nautilus พูดว่า " ความจุรวม: 250.0 GB " (แม้ว่าจะเป็น GiB จริงไม่ใช่ GB) นอกเหนือจากการติดฉลากเล็ก ๆ น้อย ๆ จนดีมาก

  • ตอนนี้พาร์ทิชันเดียวกันจัดรูปแบบเป็น ext4 กับ gparted:

ป้อนคำอธิบายรูปภาพที่นี่

First, Last and Total sector เหมือนกัน เป็นพาร์ติชัน 250GiB เดียวกัน ขนาดที่ใช้คือ 4.11GiB (บล็อกที่สงวนไว้อาจจะ?)

ป้อนคำอธิบายรูปภาพที่นี่

Nope ดูเหมือนว่าบล็อกที่สงวนไว้คือ 12.7 GiB (~ 5%. ouch! ) แต่ ... ทำไมความจุรวมถึงตอนนี้เหลือเพียง 246.1 GiB ??? . ความแตกต่างนั้น (เรียงลำดับ) ตรงกับ 4.11 GiB ที่รายงานโดย gparted แต่ ... ถ้าไม่ใช่จากบล็อกที่สำรองไว้มันคืออะไร? และทำไม gparted ไม่ได้รายงานว่า 12.7GiB ของพื้นที่ใช้แล้ว

$ df -h /dev/sda5
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             247G  188M  234G   1% /media/BACKUP

dfจับคู่ Nautilus ในพื้นที่ว่างที่รายงาน แต่ .. มีเพียง 188M เท่านั้นที่ใช้? ไม่ควรจะเป็น ~ 12GB? และความจุรวมยังคงผิด ดังนั้นฉันจึงวิ่งtune2fsไปหาเบาะแสบางอย่าง (เอาต์พุตที่ไม่เกี่ยวข้องคือ ommited)

$ sudo tune2fs -l /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   BACKUP
Filesystem UUID:          613d592e-47f5-4206-96a7-210090d340ef
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Filesystem state:         clean
Filesystem OS type:       Linux
Block count:              65536000
Reserved block count:     3276800
Free blocks:              64459851
First block:              0
Block size:               4096

65536000 บล็อกรวม * 4096 ไบต์ / บล็อก = 268435456000 ไบต์ = 268.4 GB = 250 GiB มันตรงกับ gparted

บล็อกสำรอง 3276800 = 13421772800 ไบต์ = 13.4 GB = 12.5 GiB มัน (อีกครั้งเรียงลำดับ) ตรงกับ Nautilus

บล็อกฟรี 64459851 = 264027549696 ไบต์ = 264.0 GB = 245.9 GiB ทำไม? ไม่ควรเป็น 250-12.5 = 237.5 (หรือ 250- (12.5 + 4.11) = ~ 233)?

การลบบล็อกที่สงวนไว้:

$ sudo tune2fs -m 0 /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Setting reserved blocks percentage to 0% (0 blocks)

$ sudo tune2fs -l /dev/sda5
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   BACKUP
Filesystem UUID:          613d592e-47f5-4206-96a7-210090d340ef
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Filesystem state:         clean
Filesystem OS type:       Linux
Block count:              65536000
Reserved block count:     0
Free blocks:              64459851
Block size:               4096

เป็นที่คาดหวังนับเดียวกันบล็อก 0 บล็อกลิขสิทธิ์ แต่ ... บล็อกฟรีเดียวกัน ? ฉันไม่ได้เป็นอิสระ 12.5 GiB ใช่ไหม

$ df -h /dev/sda5
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             247G  188M  246G   1% /media/BACKUP

ป้อนคำอธิบายรูปภาพที่นี่

ดูเหมือนว่าฉันทำ พื้นที่ว่างเพิ่มขึ้นจาก 233 เป็น 245.9 GiB GParted ดูแลไม่ได้ที่ทุกคนแสดงให้เห็นว่าข้อมูลเดียวกัน! (ไม่มีประโยชน์ที่จะโพสต์ภาพหน้าจอที่เหมือนกัน)

เป็นเรื่องใหญ่มาก!

ฉันพยายามจัดทำเอกสารให้ดีที่สุดเท่าที่จะทำได้ ... ดังนั้นได้โปรดให้ใครช่วยบอกฉันหน่อยได้ไหมว่าเกิดอะไรขึ้นที่นี่?

  • อะไรคือข้อผิดพลาด 4.11 GiB ที่ขาดหายไปจากการจัดรูปแบบ NTFS -> ext4
  • ทำไมมีความแตกต่างมากมายระหว่าง gparted, Nautilus, tune2fs, df?
  • คณิตศาสตร์ของฉันมีอะไรผิดปกติ? (คำถามเป็นตัวหนากระจายโพสต์นี้)

ความช่วยเหลือใด ๆ ที่ชื่นชม ในขณะที่ฉันไม่สามารถคิดได้ว่าเกิดอะไรขึ้นฉันกำลังพิจารณาที่จะเลิกใช้ ext4 แทน NTFS สำหรับทุกอย่างยกเว้นพาร์ติชัน / ของฉัน

ขอบคุณ!




@Uri Herrera: คุณอ่านคำถามของฉันจริงหรืออย่างน้อยสองบรรทัดแรก? นี่ไม่ใช่ปัญหา GiB / GB พาร์ติชันคือ 268.4GB = 250.0GiB ไม่ใช่ 246.1
— MestreLion

1
อีกคำตอบที่คุณสามารถดูได้ที่: askubuntu.com/questions/5335/…
— enzotib

คำตอบ:


13

มีบางสิ่งเกิดขึ้นที่นี่ gparted รายงานพื้นที่ใช้งานจริง / ว่าง เคอร์เนลช่วยลดจำนวนที่มีอยู่โดยพื้นที่ที่สงวนไว้ หลังจากคุณลบพื้นที่สงวนออกจำนวนฟรีไม่เปลี่ยนเนื่องจากบล็อกที่สงวนไว้ว่างแล้ว เป็นเพียงการที่ผู้ใช้ที่ไม่ใช่รูทไม่ได้รับอนุญาตให้บุกรุกพื้นที่นั้นเพื่อป้องกันไม่ให้เกิดปัญหาโดยการเติมดิสก์ ตัวเลขคำพังเพยเป็นขุยเล็ก ๆ น้อย ๆ เนื่องจากมีข้อผิดพลาด แทนที่จะรายงานพื้นที่ที่ใช้ซึ่งเคอร์เนลรายงาน (และ df แสดง) มันคำนวณโดยการลบพื้นที่ว่างจากผลรวม สิ่งนี้ทำให้แสดงพื้นที่สงวนตามที่ใช้

การใช้ 4GB ที่หายไปจริง ๆ คือ fs overhead สำหรับ ext4 ในขั้นต้น NTFS จะจัดสรรพื้นที่เพียงเล็กน้อยสำหรับ MFT เท่านั้นและจะขยายตามความต้องการ แม้ว่า ext ของระบบไฟล์จะจัดสรรพื้นที่สำหรับตาราง inode (เทียบเท่าคร่าวๆของ MFT) ในรูปแบบเวลาและไม่สามารถเติบโตได้ พื้นที่ที่หายไปจากพื้นที่ทั้งหมดที่รายงานคือตาราง inode พื้นที่ใช้งานที่เหลืออยู่นั้นมาจากวารสาร (โดยปกติคือ 128 mb) และปรับขนาด inodes


ขอบคุณ +1 สำหรับไขปริศนาบางอย่าง! แต่ถ้า ~ 4GB เป็นค่าใช้จ่ายระบบไฟล์ทำไมบางส่วนของมัน (3.9GB) ถูกหักออกจากพื้นที่ทั้งหมดในขณะที่ 188MB แสดงตามที่ใช้จริง ค่าใช้จ่ายใด (หรือทั้งคู่) และทำไมการจัดการแตกต่างกันอย่างไร นอกจากนี้dfแม้จะมี sudo แสดงความจุรวม (247GB) และพื้นที่ใช้งาน (188MB) เช่น Nautilus ดังนั้นถ้ามันเป็นบั๊กมันไม่ใช่แค่คำพังเพยเท่านั้น
— MestreLion

ฉันคิดว่า 188MB เป็นค่าใช้จ่าย (เมื่อเทียบกับ 72MB จาก NTFS) แต่ถ้าค่าใช้จ่ายของระบบไฟล์ NTFS จะเพิ่มขึ้นตามเวลานั่นหมายความว่า Nautilus จะรายงานในภายหลังว่าเป็นความจุโดยรวมที่ลดลงหรือไม่
— MestreLion

การแก้ไข: df แสดงพื้นที่ว่างเสมอไม่ว่าใครจะทำงาน เพื่อดูพื้นที่ฟรี (== พื้นที่ว่าง + พื้นที่ที่สงวนไว้) stat -f /media/BACKUPการใช้งาน
— Marius Gedminas

แก้ไขคำตอบเพื่อชี้แจง และฉันเชื่อว่าระบบไฟล์ NTFS จะรายงานพื้นที่ใช้งานเพิ่มเติมไม่หดตัวลงเมื่อ MFT เติบโตขึ้น @Marius นี้ไม่ถูกต้องเช่นกัน statfs () และด้วยเหตุนี้ทั้ง df และ stat -f ทั้งคู่แสดงพื้นที่ที่มีอยู่ซึ่งไม่นับบล็อกที่สงวนไว้ ฉันอาจสาบานได้ว่ามันปรับสำหรับโควต้าและตอบสนองการใช้งานที่หลากหลายตามผู้ใช้ที่โทรเข้ามา แต่คุณพูดถูก ไม่นับโควต้าและไม่สนใจสิ่งที่ผู้ใช้เรียก
— psusi

@psusi: ดังนั้นฉันจึงมีตารางไอโหนด ~ 3.9GiB และวารสารประมาณ 188MB + บางอย่าง? และ Nautilus ลบตาราง inode จากขนาดรวมในขณะที่รายงานสมุดรายวันเป็นพื้นที่ใช้แล้ว และรายงานให้พวกเขาทราบว่าเป็นพื้นที่ใช้งานเพียง 4.11GiB หรือไม่ ถูกต้องหรือไม่ ถ้าเป็นเช่นนั้นฉันแค่อยากให้ Nautilus จัดการค่าใช้จ่ายทั้งสองในลักษณะเดียวกัน .. ทั้งสองถูกลบออกจากทั้งหมดหรือทั้งสองอย่างนับว่าเป็น "พื้นที่ใช้แล้ว" (ดีกว่า)
— MestreLion

7

ก่อนอื่นบล็อกที่สงวนไว้จะไม่ถูกบล็อกที่ใช้สำหรับการจัดการภายในระบบไฟล์

บล็อกสงวนถูกสงวนไว้เพียงเพื่อrootให้มั่นใจว่าบริการที่ใช้ไฟล์บนพาร์ติชันนั้นไม่สามารถถูกแยกออกจากพื้นที่โดยผู้ใช้ที่ไม่ใช่ผู้ดูแลระบบบางคนเติมเต็มพื้นที่ทั้งหมด

แม้จะไม่มีบล็อกที่สงวนไว้ ( -m 0) มีพื้นที่ส่วนหนึ่งที่ใช้สำหรับการจัดการภายในระบบแฟ้มฉันก็ไม่สามารถพูดได้ว่าฉันไม่มีความรู้ลึกซึ้ง

นอกจากนี้Gpartedจะถูกดำเนินการเช่นrootกันดังนั้นจึงเห็นบล็อกที่สงวนไว้ว่าว่าง Nautilusดำเนินการในฐานะผู้ใช้ดูว่าไม่ว่าง

ตกลง @psusi คำตอบชัดเจนมากฉันไม่มีอะไรเพิ่ม


Humm มีข้อมูลมาก +1 อย่างน้อยก็แก้ปัญหาที่ฉันพบ การเห็นบล็อกที่สงวนไว้เป็น "ขีด จำกัด ขีด จำกัด " สำหรับผู้ที่ไม่ใช่รูทแทนที่จะเป็น "บล็อกที่ใช้แล้ว" ทำให้การอ่าน gparted, df และ tune2fs เป็นไปตามที่ตกลงกัน (และสมเหตุสมผล) แต่บางคำถามยังคงอยู่โดยเฉพาะพื้นที่ใช้งาน 4GB / ความจุทั้งหมด
— MestreLion

1
นอกจากนี้ฉันได้อ่านบางที่ (หนึ่งในนั้น "ทำไมคุณไม่จำเป็นต้องจัดเรียงข้อมูลพาร์ติชัน Linux ของคุณทุกเดือน" HOWTOs อาจจะ?) ที่จองพื้นที่ 5% สำหรับรากให้พื้นที่การหายใจไปยังอัลกอริทึมการจัดสรร extN และหลีกเลี่ยง การกระจายตัวของ
— Marius Gedminas

1

ลองลดขนาดพาร์ติชันลงสักสองสามเมกะไบต์โดยใช้ gparted จากนั้นเพิ่มขนาดให้เป็นขนาดดั้งเดิม นี่อาจทำให้แอปพลิเคชันอื่นอ่านขนาดอย่างถูกต้อง ฉันเพิ่งแก้ไขข้อผิดพลาด 50Gb ด้วยวิธีนี้!

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