`ls -s` พิมพ์“ 0” เมื่อใด

แน่นอนวิธีมาตรฐานในการทดสอบว่าไฟล์ว่างเปล่าtest -s FILEแต่ลูกค้าคนหนึ่งของเราได้รับสคริปต์ที่มีการทดสอบดังนี้:

RETVAL=`ls -s ./log/cr_trig.log | awk '{print $1}'`
if test $RETVAL -ne 0
then
    echo "Badness: Log not empty"
    exit 25
fi

ด้วยการอ้างสิทธิ์จากซัพพลายเออร์ว่าทำงานได้ในสภาพแวดล้อมทั้งสองที่พวกเขาได้ทำการทดสอบมาโดยไม่จำเป็นต้องบอกว่ามันล้มเหลวทั้งสองแห่งที่ฉันทดสอบ

ดังนั้นฉันอยากรู้ เมื่อไหร่ls -sพิมพ์0ไฟล์เปล่า?

นี่คือสิ่งที่ฉันค้นพบ:

• GFS บน Linux: 4
• ext4 บน Linux: 0
• ZFS บน Solaris: 1
• UFS บน Solaris: 0
• jfs บน AIX: 0
• VxFS บน HP-UX: 0
• HFS บน HP-UX: 0
• HFS บน Mac OS X: 0

ฉันยังไม่ได้ตรวจสอบระบบไฟล์ในเครือข่าย

คำถาม: ฉันจะอธิบายให้คนอื่นฟังว่าสคริปต์ของพวกเขาผิดไปได้อย่างไร?

ในความคิดของฉันรุ่น "ถูกต้อง" จะเป็น:

if test ! -s ./log/cr_trig.log
then
    echo "Badness: Log not empty"
    exit 25
fi

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

สำหรับคำถามของคุณ: ตามที่Matได้แสดงความคิดเห็นไว้แล้วให้พวกเขาแสดงผลการทดสอบของคุณ เพื่ออธิบายผลลัพธ์ให้พวกเขาระบุว่าls -sรายงานจำนวนบล็อกที่จัดสรรในระบบไฟล์ไม่ใช่ขนาดจริงเป็นไบต์ เห็นได้ชัดว่าการใช้งานระบบไฟล์บางส่วนจัดสรรบล็อกแม้ว่าพวกเขาไม่จำเป็นต้องเก็บข้อมูลใด ๆ แทนที่จะเก็บเพียงตัวชี้ NULL ในไอโหนด

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

แต่โดยปกติแล้วไฟล์ที่สร้างขึ้นจะได้รับข้อมูลบางอย่างในไม่ช้าดังนั้นนักออกแบบของ FS ที่แน่นอนอาจสันนิษฐานว่ามันจ่ายออกเพื่อจัดสรรบล็อกข้อมูลทันทีเมื่อสร้างไฟล์ดังนั้นเมื่อข้อมูลแรกมาถึงงานนี้เสร็จเรียบร้อยแล้ว

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

แก้ไข:

อีกเหตุผลหนึ่งที่ควรคำนึงถึง: ระบบไฟล์ที่คุณพบค่า> 0 คือZFS , การใช้งาน RAID + LVM + FS และGFS , ระบบไฟล์คลัสเตอร์ ทั้งคู่อาจต้องเก็บข้อมูลเมตาเพื่อรักษาความสมบูรณ์ของไฟล์ที่ไม่ได้เก็บไว้ใน inodes อาจเป็นได้ว่าls -sจำนวนนั้นในบล็อกข้อมูลที่จัดสรรสำหรับข้อมูลเมตานี้

ไม่เหมือนกับระบบไฟล์อื่น ๆ ส่วนใหญ่ (ถ้าไม่ใช่ทั้งหมด) ZFS จะไม่จัดสรรล่วงหน้าแบบคงที่ของ inodes การสร้างไฟล์ที่ว่างเปล่าใน ZFS ls -sแล้วจะใช้บล็อกใหม่ของข้อมูลซึ่งเป็นหนึ่งที่รายงานโดย

ฉันสงสัยว่า GFS ต้องเก็บข้อมูลการซิงค์ / ล็อคที่นำไปสู่ผลลัพธ์ที่ไม่ใช่ศูนย์อื่น ๆ

ls -s รายงานจำนวนบล็อกที่ถูกจัดสรรสำหรับไฟล์ไม่รวมสิ่งที่ถูกเก็บไว้ในรายการไดเร็กทอรีโดยตรง

ในกรณีส่วนใหญ่จำนวนบล็อกคือจำนวนไบต์หารด้วยขนาดบล็อกเป็นไบต์ปัดเศษขึ้น

จำนวนบล็อกสามารถน้อยกว่าที่หาไฟล์เบาบาง ตัวอย่างเช่นในระบบไฟล์ส่วนใหญ่สิ่งนี้จะสร้างไฟล์ 8192- ไบต์ซึ่งประกอบไปด้วยบล็อก 0 บล็อก:

$ perl -e 'truncate STDOUT, 8192' >a
$ ls -l a
-rw-r--r-- 1 gilles gilles 8192 Nov  1 21:32 a
$ ls -s a
0 a

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

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