ระบบไฟล์ที่มีโครงสร้างแบบ Copy-on-Write และ Log อาจให้ประสิทธิภาพที่ดีกว่าบนดิสก์แบบ shingled โดยลดการลดการเขียนแบบสุ่ม มาตรฐานค่อนข้างสนับสนุนสิ่งนี้อย่างไรก็ตามความแตกต่างเหล่านี้ในการปฏิบัติงานไม่ได้เฉพาะเจาะจงกับดิสก์ที่มีการซ้อนกัน พวกเขายังเกิดขึ้นบนดิสก์ที่ไม่ได้โกนที่ใช้เป็นตัวควบคุม ดังนั้นการเปลี่ยนไปใช้ดิสก์แบบ shingled อาจไม่มีความเกี่ยวข้องกับระบบไฟล์ที่คุณเลือก
ระบบไฟล์ nilfs2 ให้ประสิทธิภาพค่อนข้างดีบนดิสก์ SMR อย่างไรก็ตามนี่เป็นเพราะฉันจัดสรรพาร์ติชั่น 8TB ทั้งตัวและเกณฑ์มาตรฐานเขียนแค่ 0.5TB เท่านั้นดังนั้นตัวทำความสะอาด nilfs จึงไม่ต้องทำงาน เมื่อฉัน จำกัด พาร์ติชั่นไว้ที่ 200GB เบนช์มาร์กของ nilfs ก็ยังไม่เสร็จสมบูรณ์ Nilfs2 อาจเป็นตัวเลือกที่เหมาะกับการใช้งานหากคุณใช้ดิสก์ "เก็บถาวร" เป็นดิสก์เก็บถาวรซึ่งคุณเก็บข้อมูลและสแน็ปช็อตทั้งหมดที่เขียนลงในดิสก์ตลอดไปจากนั้น nilfs cleaner ไม่ต้องทำงาน
ฉันเข้าใจว่าST8000AS0002-1NA17Zไดรฟ์ซีเกทขนาด 8TB ที่ฉันใช้ในการทดสอบมีพื้นที่แคช~ 20GB ฉันได้เปลี่ยนการตั้งค่าเริ่มต้นของ filebench fileserver เพื่อให้ชุดเบนช์มาร์กมีขนาด ~ 125GB ซึ่งใหญ่กว่าพื้นที่แคช unshingled:
set $meanfilesize=1310720
set $nfiles=100000
run 36000
ตอนนี้สำหรับข้อมูลจริง จำนวนของ ops วัดประสิทธิภาพของไฟล์เซิร์ฟเวอร์ "โดยรวม" ในขณะที่ ms / op จะวัดเวลาแฝงของการผนวกแบบสุ่มและสามารถใช้เป็นแนวทางคร่าวๆสำหรับประสิทธิภาพของการเขียนแบบสุ่ม
$ grep rand *0.out | sed s/.0.out:/\ / |sed 's/ - /-/g' | column -t
SMR8TB.nilfs appendfilerand1 292176ops 8ops/s 0.1mb/s 1575.7ms/op 95884us/op-cpu [0ms - 7169ms]
SMR.btrfs appendfilerand1 214418ops 6ops/s 0.0mb/s 1780.7ms/op 47361us/op-cpu [0ms-20242ms]
SMR.ext4 appendfilerand1 172668ops 5ops/s 0.0mb/s 1328.6ms/op 25836us/op-cpu [0ms-31373ms]
SMR.xfs appendfilerand1 149254ops 4ops/s 0.0mb/s 669.9ms/op 19367us/op-cpu [0ms-19994ms]
Toshiba.btrfs appendfilerand1 634755ops 18ops/s 0.1mb/s 652.5ms/op 62758us/op-cpu [0ms-5219ms]
Toshiba.ext4 appendfilerand1 466044ops 13ops/s 0.1mb/s 270.6ms/op 23689us/op-cpu [0ms-4239ms]
Toshiba.xfs appendfilerand1 368670ops 10ops/s 0.1mb/s 195.6ms/op 19084us/op-cpu [0ms-2994ms]
เนื่องจากซีเกทเป็น 5980 รอบต่อนาทีเราอาจคาดหวังว่าโตชิบาจะเร็วกว่านี้ถึง 20% การวัดประสิทธิภาพเหล่านี้แสดงให้เห็นว่าเร็วกว่าประมาณ 3 เท่า (200%) ดังนั้นมาตรฐานเหล่านี้จึงส่งผลต่อประสิทธิภาพการทำงาน เราเห็นดิสก์ Shingled (SMR) ยังไม่สามารถจับคู่ ext4 ประสิทธิภาพกับดิสก์ unshingled (PMR) ประสิทธิภาพที่ดีที่สุดคือกับ nilfs2 ที่มีพาร์ติชัน 8TB (ดังนั้นตัวทำความสะอาดไม่จำเป็นต้องทำงาน) แต่ถึงอย่างนั้นช้ากว่า Toshiba ที่มี ext4 อย่างมีนัยสำคัญ
ในการทำให้การวัดประสิทธิภาพด้านบนมีความชัดเจนมากขึ้นอาจช่วยทำให้มาตรฐานเหล่านั้นเป็นปกติเมื่อเทียบกับประสิทธิภาพของ ext4 ในแต่ละดิสก์:
ops randappend
SMR.btrfs: 1.24 0.74
SMR.ext4: 1 1
SMR.xfs: 0.86 1.98
Toshiba.btrfs: 1.36 0.41
Toshiba.ext4: 1 1
Toshiba.xfs: 0.79 1.38
เราเห็นว่าในดิสก์ SMR btrfs มีข้อได้เปรียบส่วนใหญ่ในการใช้งานโดยรวมที่มีใน ext4 แต่การลงโทษในภาคผนวกแบบสุ่มนั้นไม่ได้มีความสำคัญเท่ากับอัตราส่วน สิ่งนี้อาจนำไปสู่การย้ายไปยัง btrfs บนดิสก์ SMR ในทางกลับกันถ้าคุณต้องการผนวกแบบสุ่มเวลาแฝงต่ำเกณฑ์มาตรฐานนี้แนะนำให้คุณต้องการ xfs โดยเฉพาะอย่างยิ่ง SMR เราเห็นว่าในขณะที่ SMR / PMR อาจมีผลต่อการเลือกระบบไฟล์ของคุณการพิจารณาปริมาณงานที่คุณปรับให้เหมาะสมนั้นมีความสำคัญมากกว่า
ฉันยังใช้มาตรฐานอ้างอิงห้องใต้หลังคา ระยะเวลาของการรันห้องใต้หลังคา (บนพาร์ติชันดิสก์เต็ม 8TB SMR) คือ:
ext4: 1 days 1 hours 19 minutes 54.69 seconds
btrfs: 1 days 40 minutes 8.93 seconds
nilfs: 22 hours 12 minutes 26.89 seconds
ในแต่ละกรณีที่เก็บใต้หลังคามีสถิติต่อไปนี้:
Original size Compressed size Deduplicated size
This archive: 1.00 TB 639.69 GB 515.84 GB
All archives: 901.92 GB 639.69 GB 515.84 GB
การเพิ่มสำเนาที่สองของดิสก์ 1 TB เดียวกันลงในห้องใต้หลังคาใช้เวลา 4.5 ชั่วโมงในแต่ละระบบไฟล์ทั้งสามนี้ การถ่ายโอนข้อมูลดิบของข้อมูลอ้างอิงและsmartctlข้อมูลอยู่ที่:
http://pastebin.com/tYK2Uj76
https://github.com/gmatht/joshell/tree/master/benchmarks/SMR