df -h แสดงเอาต์พุตไม่ถูกต้องในหน่วย GB

หากฉันแสดงรายการเอาต์พุต df สำหรับ KB, MB และ GB รายการเหล่านั้นไม่ตรงกันเช่น

$ df -k |grep xvdb
/dev/xvdb1            12796048    732812  11413172   7% /xxx
$ df -m |grep xvdb
/dev/xvdb1               12497       716     11146   7% /xxx
$ df -h |grep xvdb
/dev/xvdb1             13G  716M   11G   7% /xxx

• 12796048 KB = 12496.14 MB ดังนั้นจึงปิดเล็กน้อย แต่ก็ใช้ได้
• 12796048 KB = 12.2 GB, 12407 MB ก็เป็น 12.2 GB เช่นกัน

เหตุใด df จึงแสดง 13 GB หรือฉันหายไปบางอย่าง

นี่คือรายการ df เต็ม

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            7.5G  1.7G  5.5G  24% /
none                  5.8G  128K  5.8G   1% /dev
none                  5.8G     0  5.8G   0% /dev/shm
none                  5.8G   44K  5.8G   1% /var/run
none                  5.8G     0  5.8G   0% /var/lock
none                  5.8G     0  5.8G   0% /lib/init/rw
/dev/xvdb1             13G  716M   11G   6% /xxx

รุ่น Coreutils ดูเหมือนจะเป็น 7.4 info coreutils แสดงให้เห็นว่า

เอกสารคู่มือนี้เวอร์ชัน 7.4 ของยูทิลิตี้หลักของ GNU

df ปัดเศษเอาต์พุตที่มนุษย์อ่านได้เสมอ ( -h และ -H )

จากซอร์สโค้ดในแพ็คเกจ coreutils lib/human.hตัวเลือก enum สำหรับ human_readable ฟังก์ชั่นให้ปัดเศษหน่วยแปลง ฯลฯ :

/* Options for human_readable.  */
enum
{
  /* Unless otherwise specified these options may be ORed together.  */

  /* The following three options are mutually exclusive.  */
  /* Round to plus infinity (default).  */
  human_ceiling = 0,
  /* Round to nearest, ties to even.  */
  human_round_to_nearest = 1,
  /* Round to minus infinity.  */
  human_floor = 2,
...

หมายเหตุความคิดเห็น: Round to plus infinity (default).

การปัดเศษที่เกิดขึ้นจริงเกิดขึ้นในฟังก์ชั่นต่อไปนี้มา human.cซึ่งเพิ่ม true (นั่นคือ 1 ) หากไม่มีการตั้งค่าตัวเลือกการปัดเศษอื่นที่แสดงไว้ด้านบน (ไม่ใช่ -h ชุดเท่านั้น human_autoscale | human_SI | human_base_1024ซึ่งส่งผลให้การปรับขนาดอัตโนมัติใช้ 1024 เป็นการเพิ่มหน่วยและพิมพ์ส่วนต่อท้ายสไตล์ SI ได้แก่ G ) และค่าไม่ใช่จำนวนเต็ม:

static long double
adjust_value (int inexact_style, long double value)
{
  /* Do not use the floorl or ceill functions, as that would mean
     checking for their presence and possibly linking with the
     standard math library, which is a porting pain.  So leave the
     value alone if it is too large to easily round.  */
  if (inexact_style != human_round_to_nearest && value < UINTMAX_MAX)
    {
      uintmax_t u = value;
      value = u + (inexact_style == human_ceiling && u != value);
    }

  return value;
}

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

วิกิพีเดีย :   สิ่งนี้นำไปสู่ความไม่มีประสิทธิภาพของพื้นที่เนื่องจากการแตกแฟรกเมนต์ภายในเนื่องจากความยาวไฟล์มักไม่ใช่จำนวนเต็มของบล็อกจำนวนเต็มและบล็อกสุดท้ายของไฟล์จะยังคงว่างเปล่าบางส่วน สิ่งนี้จะสร้างพื้นที่หย่อนซึ่งเฉลี่ยครึ่งบล็อกต่อไฟล์ ระบบไฟล์ที่ใหม่กว่าบางระบบพยายามที่จะแก้ปัญหานี้ผ่านเทคนิคที่เรียกว่าการจัดสรรบล็อกย่อยและการรวมส่วนท้าย

แก้ไข :

หน้าคนบอกว่า:

SIZE อาจเป็น (หรืออาจจะเป็นจำนวนเต็มก็ได้) หนึ่งในนั้น          lowing: kB 1000, K 1024, MB 1000 * 1000, M 1024 * 1024 และอื่น ๆ สำหรับ G, T,          P, E, Z, Y

นั่นทำให้ฉันเชื่อว่าอาจใช้ MB แทน M ดังนั้นอาจแสดง 12.796 - อาจปัดเศษเป็น 13

ประสบการณ์ล่าสุดของฉันกับระบบไฟล์หลายเทราไบต์คือการปรับขนาดใน 'df -h' อาจทำให้เกิดความสับสนเนื่องจากคอลัมน์ 'ขนาดรวม' ถูกปัดเศษเป็นจำนวนเต็มและสูงตลอดในขณะที่คอลัมน์ 'ใช้' และ 'พร้อม' ถูกปรับขนาดและปัดเศษเป็นทศนิยม 1 ตำแหน่ง สิ่งนี้สามารถทำให้การแสดงขนาดโดยรวมเกือบเป็น 'หน่วย' ทั้งหมดที่ใหญ่กว่ามัน ผลที่เห็นได้ชัดเจนที่สุดคือขนาดที่คุณเป็นจำนวนน้อยไม่ว่าจะเป็น MB, GB หรือ TB