ฤดูใบไม้ผลินี้ เราได้พูดคุยกันถึงหัวข้อเบื้องต้นแล้ว เช่น и . ในข้อที่สอง เราสัญญาว่าจะศึกษาประสิทธิภาพของโทโพโลยีหลายดิสก์ใน ZFS ต่อไป นี่คือระบบไฟล์เจเนอเรชันถัดไปที่ตอนนี้ถูกนำไปใช้งานทุกที่: จาก ไปยัง .
วันนี้เป็นวันที่ดีที่สุดที่จะทำความคุ้นเคยกับ ZFS ผู้อ่านที่อยากรู้อยากเห็น เพียงแค่รู้ว่าในความคิดเห็นที่ต่ำต้อยของนักพัฒนา OpenZFS Matt Ahrens "มันยากจริงๆ"
แต่ก่อนที่เราจะไปถึงตัวเลข - ฉันสัญญา - สำหรับตัวเลือกทั้งหมดสำหรับการกำหนดค่า ZFS แปดดิสก์เราต้องพูดถึง ในขณะที่ โดยทั่วไป ZFS จะเก็บข้อมูลไว้ในดิสก์
Zpool, vdev และอุปกรณ์
แผนภาพพูลแบบเต็มนี้ประกอบด้วย vdevs เสริมสามตัว แต่ละคลาสหนึ่งตัว และสี่ตัวสำหรับ RAIDz2
โดยปกติแล้วไม่มีเหตุผลใดที่จะสร้างพูลของประเภทและขนาด vdev ที่ไม่ตรงกัน - แต่ไม่มีอะไรหยุดคุณจากการทำเช่นนั้นหากคุณต้องการ
เพื่อให้เข้าใจระบบไฟล์ ZFS อย่างแท้จริง คุณต้องศึกษาโครงสร้างจริงอย่างละเอียด ประการแรก ZFS รวมการจัดการระดับเสียงและระบบไฟล์แบบดั้งเดิมเข้าด้วยกัน ประการที่สอง จะใช้กลไกการคัดลอกเมื่อเขียนธุรกรรม คุณสมบัติเหล่านี้หมายความว่าระบบมีโครงสร้างที่แตกต่างจากระบบไฟล์ทั่วไปและอาร์เรย์ RAID อย่างมาก หน่วยการสร้างพื้นฐานชุดแรกที่ต้องทำความเข้าใจคือพูลหน่วยเก็บข้อมูล (zpool) อุปกรณ์เสมือน (vdev) และอุปกรณ์จริง (อุปกรณ์)
zpool
พูลหน่วยเก็บข้อมูล zpool เป็นโครงสร้าง ZFS ที่อยู่บนสุด แต่ละพูลมีอุปกรณ์เสมือนตั้งแต่หนึ่งเครื่องขึ้นไป ในทางกลับกัน แต่ละอุปกรณ์มีอุปกรณ์ (อุปกรณ์) จริงอย่างน้อยหนึ่งเครื่อง สระเสมือนเป็นบล็อกที่มีในตัวเอง ฟิสิคัลคอมพิวเตอร์หนึ่งเครื่องสามารถมีพูลแยกกันตั้งแต่สองพูลขึ้นไป แต่แต่ละพูลจะเป็นอิสระจากกันโดยสิ้นเชิง พูลไม่สามารถแชร์อุปกรณ์เสมือนได้
ความซ้ำซ้อนของ ZFS อยู่ที่ระดับอุปกรณ์เสมือน ไม่ใช่ที่ระดับพูล ไม่มีความซ้ำซ้อนอย่างแน่นอนที่ระดับพูล - หากไดรฟ์ vdev หรือ vdev พิเศษสูญหาย พูลทั้งหมดก็จะสูญหายตามไปด้วย
พูลหน่วยเก็บข้อมูลสมัยใหม่สามารถรอดพ้นจากการสูญหายของแคชหรือบันทึกอุปกรณ์เสมือน แม้ว่าพวกเขาอาจสูญเสียข้อมูลสกปรกจำนวนเล็กน้อยหากพวกเขาสูญเสียบันทึก vdev ในระหว่างที่ไฟฟ้าดับหรือระบบขัดข้อง
มีความเข้าใจผิดกันทั่วไปว่า "แถบข้อมูล" ของ ZFS ถูกเขียนทั่วทั้งกลุ่ม นี่ไม่เป็นความจริง. Zpool ไม่ตลก RAID0 เลย มันค่อนข้างตลก ด้วยกลไกการกระจายตัวแปรที่ซับซ้อน
โดยส่วนใหญ่ บันทึกจะถูกกระจายไปยังอุปกรณ์เสมือนที่มีอยู่ตามพื้นที่ว่างที่มีอยู่ ดังนั้นตามทฤษฎีแล้ว บันทึกทั้งหมดจะถูกเติมเต็มในเวลาเดียวกัน ZFS เวอร์ชันล่าสุดคำนึงถึงการใช้งาน vdev ในปัจจุบัน (การกำจัด) - หากอุปกรณ์เสมือนตัวหนึ่งยุ่งกว่าอีกตัวหนึ่งอย่างมาก (เช่น เนื่องจากโหลดการอ่าน) อุปกรณ์จะถูกข้ามชั่วคราวเพื่อเขียน แม้ว่าจะมีอัตราส่วนพื้นที่ว่างสูงสุด .
กลไกการตรวจจับการรีไซเคิลที่สร้างไว้ในวิธีการจัดสรรการเขียน ZFS สมัยใหม่สามารถลดเวลาแฝงและเพิ่มปริมาณงานในช่วงที่มีภาระงานสูงผิดปกติ - แต่ก็ไม่ได้ อาหารตามสั่งบลานช์ เพื่อการผสม HDD ที่ช้าและ SSD ที่รวดเร็วโดยไม่สมัครใจในกลุ่มเดียว พูลที่ไม่เท่ากันดังกล่าวจะยังคงทำงานที่ความเร็วของอุปกรณ์ที่ช้าที่สุด นั่นคือ ราวกับว่ามันประกอบด้วยอุปกรณ์ดังกล่าวทั้งหมด
วีเดฟ
แต่ละพูลหน่วยเก็บข้อมูลประกอบด้วยอุปกรณ์เสมือนอย่างน้อยหนึ่งเครื่อง (อุปกรณ์เสมือน, vdev) ในทางกลับกัน แต่ละ vdev จะมีอุปกรณ์จริงอย่างน้อยหนึ่งเครื่อง อุปกรณ์เสมือนส่วนใหญ่ใช้สำหรับจัดเก็บข้อมูลอย่างง่าย แต่มีคลาสตัวช่วย vdev หลายคลาส รวมถึง CACHE, LOG และ SPECIAL vdev แต่ละประเภทเหล่านี้สามารถมีหนึ่งในห้าโทโพโลยี: อุปกรณ์เดียว (อุปกรณ์เดียว), RAIDz1, RAIDz2, RAIDz3 หรือมิเรอร์ (มิเรอร์)
RAIDz1, RAIDz2 และ RAIDz3 เป็นรูปแบบพิเศษของสิ่งที่ผู้จับเวลารุ่นเก่าเรียกว่า RAID พาริตีแบบคู่ (แนวทแยง) 1, 2 และ 3 หมายถึงจำนวนบล็อกพาริตีที่ถูกจัดสรรสำหรับแถบข้อมูลแต่ละแถบ แทนที่จะแยกดิสก์สำหรับพาริตี อุปกรณ์เสมือน RAIDz จะกระจายพาริตีนี้แบบกึ่งเท่าๆ กันทั่วทั้งดิสก์ อาร์เรย์ RAIDz สามารถสูญเสียดิสก์ได้มากเท่าที่มีบล็อกพาริตี ถ้ามันเสียอีก มันจะพังและนำพูลหน่วยเก็บข้อมูลไปด้วย
ในอุปกรณ์เสมือนที่ทำมิเรอร์ (มิเรอร์ vdev) แต่ละบล็อกจะถูกจัดเก็บไว้ในอุปกรณ์แต่ละเครื่องใน vdev แม้ว่ากระจกสองบานจะเป็นที่นิยมมากที่สุด แต่อุปกรณ์จำนวนเท่าใดก็ได้ที่สามารถอยู่ในกระจกเงาได้ - มักจะใช้กระจกสามบานในการติดตั้งขนาดใหญ่เพื่อปรับปรุงประสิทธิภาพการอ่านและความทนทานต่อข้อผิดพลาด มิเรอร์ vdev สามารถรอดพ้นจากความล้มเหลวใดๆ ตราบใดที่อุปกรณ์อย่างน้อยหนึ่งตัวใน vdev ยังคงทำงานต่อไป
vdevs เดี่ยวนั้นอันตรายโดยเนื้อแท้ อุปกรณ์เสมือนดังกล่าวจะไม่รอดจากความล้มเหลวเพียงครั้งเดียว - และหากใช้เป็นที่เก็บข้อมูลหรือ vdev พิเศษ ความล้มเหลวจะนำไปสู่การทำลายล้างของพูลทั้งหมด ระวังตัวให้มากที่นี่
สามารถสร้าง CACHE, LOG และ SPECIAL VA ได้โดยใช้โทโพโลยีใดๆ ข้างต้น แต่โปรดจำไว้ว่าการสูญเสีย SPECIAL VA หมายถึงการสูญเสียของพูล ดังนั้นขอแนะนำโทโพโลยีสำรอง
เครื่อง
นี่อาจเป็นคำที่ง่ายที่สุดในการทำความเข้าใจใน ZFS - แท้จริงแล้วเป็นอุปกรณ์เข้าถึงโดยสุ่มแบบบล็อก โปรดจำไว้ว่าอุปกรณ์เสมือนประกอบด้วยอุปกรณ์แต่ละชิ้น ในขณะที่พูลประกอบด้วยอุปกรณ์เสมือน
ดิสก์ - ไม่ว่าจะเป็นสถานะแม่เหล็กหรือโซลิด - เป็นอุปกรณ์บล็อกทั่วไปที่ใช้เป็นส่วนประกอบพื้นฐานของ vdev อย่างไรก็ตาม อุปกรณ์ใดๆ ที่มีคำอธิบายใน /dev จะทำ ดังนั้นอาร์เรย์ RAID ของฮาร์ดแวร์ทั้งหมดสามารถใช้เป็นอุปกรณ์แยกต่างหากได้
ไฟล์ raw อย่างง่ายเป็นหนึ่งในอุปกรณ์บล็อกทางเลือกที่สำคัญที่สุดที่ vdev สามารถสร้างได้ สระทดสอบจาก เป็นวิธีที่สะดวกมากในการตรวจสอบคำสั่งพูลและดูว่ามีพื้นที่ว่างเท่าใดในพูลหรืออุปกรณ์เสมือนของโทโพโลยีที่กำหนด
คุณสามารถสร้างพูลทดสอบจากไฟล์ที่กระจัดกระจายได้ในเวลาเพียงไม่กี่วินาที แต่อย่าลืมลบพูลทั้งหมดและส่วนประกอบหลังจากนั้น
สมมติว่าคุณต้องการเซิร์ฟเวอร์แปดดิสก์และวางแผนที่จะใช้ดิสก์ขนาด 10 TB (~9300 GiB) แต่คุณไม่แน่ใจว่าโทโพโลยีใดที่เหมาะกับความต้องการของคุณมากที่สุด ในตัวอย่างด้านบน เราสร้างพูลทดสอบจากไฟล์กระจัดกระจายในเวลาไม่กี่วินาที และตอนนี้เรารู้แล้วว่า RAIDz2 vdev ที่มีดิสก์ขนาด 10 TB แปดตัวให้ความจุที่ใช้งานได้ 50 TiB
อุปกรณ์พิเศษอีกประเภทหนึ่งคืออะไหล่ อุปกรณ์ Hot-swap ต่างจากอุปกรณ์ทั่วไป ที่เป็นของพูลทั้งหมด แทนที่จะเป็นอุปกรณ์เสมือนตัวเดียว หาก vdev ใดๆ ในพูลล้มเหลวและอุปกรณ์สำรองเชื่อมต่อกับพูลและพร้อมใช้งาน อุปกรณ์จะเข้าร่วม vdev ที่ได้รับผลกระทบโดยอัตโนมัติ
หลังจากเชื่อมต่อกับ vdev ที่ได้รับผลกระทบ อุปกรณ์สำรองจะเริ่มรับสำเนาหรือสร้างข้อมูลใหม่ที่ควรอยู่ในอุปกรณ์ที่หายไป ใน RAID แบบดั้งเดิม สิ่งนี้เรียกว่าการสร้างใหม่ ในขณะที่ ZFS เรียกว่าการรีซิลเวอร์
โปรดทราบว่าอุปกรณ์สำรองไม่ได้เปลี่ยนอุปกรณ์ที่เสียอย่างถาวร นี่เป็นเพียงการแทนที่ชั่วคราวเพื่อลดระยะเวลาที่ vdev จะลดลง หลังจากที่ผู้ดูแลระบบเปลี่ยน vdev ที่ล้มเหลว ความซ้ำซ้อนจะถูกกู้คืนไปยังอุปกรณ์ถาวรนั้น และ SPARE ถูกตัดการเชื่อมต่อจาก vdev และกลับไปทำงานเป็นอะไหล่สำหรับทั้งพูล
ชุดข้อมูล บล็อก และเซกเตอร์
Building Block ชุดถัดไปที่ต้องทำความเข้าใจในการเดินทาง ZFS ของเราเกี่ยวข้องกับฮาร์ดแวร์น้อยกว่าและเกี่ยวข้องกับวิธีจัดระเบียบและจัดเก็บข้อมูลมากกว่า เรากำลังข้ามเลเยอร์บางส่วนที่นี่ เช่น metaslab เพื่อหลีกเลี่ยงไม่ให้รายละเอียดยุ่งเหยิงในขณะที่ยังคงรักษาความเข้าใจในโครงสร้างโดยรวม
ชุดข้อมูล (ชุดข้อมูล)
เมื่อเราสร้างชุดข้อมูลเป็นครั้งแรก ชุดข้อมูลจะแสดงพื้นที่พูลที่มีอยู่ทั้งหมด จากนั้นเรากำหนดโควต้า - และเปลี่ยนจุดเมานท์ มายากล!
Zvol ส่วนใหญ่เป็นเพียงชุดข้อมูลที่แยกออกจากชั้นระบบไฟล์ ซึ่งเราจะแทนที่ที่นี่ด้วยระบบไฟล์ ext4 ปกติโดยสมบูรณ์
ชุดข้อมูล ZFS นั้นเหมือนกับระบบไฟล์ที่เมาท์มาตรฐาน เช่นเดียวกับระบบไฟล์ทั่วไป แวบแรกดูเหมือนว่า "แค่โฟลเดอร์อื่น" แต่เช่นเดียวกับระบบไฟล์ที่ติดตั้งได้ทั่วไป ชุดข้อมูล ZFS แต่ละชุดมีคุณสมบัติพื้นฐานของตัวเอง
ประการแรก ชุดข้อมูลอาจมีโควต้าที่กำหนด หากคุณติดตั้ง zfs set quota=100G poolname/datasetnameจากนั้นคุณจะไม่สามารถเขียนไปยังโฟลเดอร์ที่เมาท์ได้ /poolname/datasetname มากกว่า 100 GiB
สังเกตเห็นการมีอยู่และไม่มีเครื่องหมายทับที่จุดเริ่มต้นของแต่ละบรรทัดหรือไม่ ชุดข้อมูลแต่ละชุดจะมีตำแหน่งของตัวเองทั้งในลำดับชั้น ZFS และลำดับชั้นการเมาต์ระบบ ไม่มีเครื่องหมายสแลชนำหน้าในลำดับชั้น ZFS - คุณเริ่มต้นด้วยชื่อพูล จากนั้นตามด้วยเส้นทางจากชุดข้อมูลหนึ่งไปยังชุดข้อมูลถัดไป ตัวอย่างเช่น, pool/parent/child สำหรับชุดข้อมูลชื่อ child ภายใต้ชุดข้อมูลพาเรนต์ parent ในสระที่มีชื่อที่สร้างสรรค์ pool.
ตามค่าเริ่มต้น จุดเชื่อมต่อของชุดข้อมูลจะเทียบเท่ากับชื่อในลำดับชั้น ZFS โดยมีเครื่องหมายทับนำหน้า - พูลชื่อ pool ติดตั้งเป็น /pool,ชุดข้อมูล parent ติดตั้งใน /pool/parentและชุดข้อมูลลูก child ติดตั้งใน /pool/parent/child. อย่างไรก็ตาม จุดเชื่อมต่อระบบของชุดข้อมูลสามารถเปลี่ยนแปลงได้
ถ้าเราบ่งชี้ zfs set mountpoint=/lol pool/parent/childแล้วชุดข้อมูล pool/parent/child ติดตั้งบนระบบเป็น /lol.
นอกจากชุดข้อมูลแล้ว เราควรพูดถึงปริมาณ (zvols) วอลลุมนั้นเกือบจะเหมือนกับชุดข้อมูล ยกเว้นว่าวอลลุ่มนั้นไม่มีระบบไฟล์ เป็นเพียงอุปกรณ์บล็อกเท่านั้น ตัวอย่างเช่น คุณสามารถสร้าง zvol ด้วยชื่อ mypool/myzvolจากนั้นจัดรูปแบบด้วยระบบไฟล์ ext4 จากนั้นเมานต์ระบบไฟล์นั้น - ตอนนี้คุณมีระบบไฟล์ ext4 แต่ด้วยคุณสมบัติความปลอดภัยทั้งหมดของ ZFS! สิ่งนี้อาจดูงี่เง่าในเครื่องเดียว แต่เหมาะสมกว่ามากในฐานะแบ็กเอนด์เมื่อส่งออกอุปกรณ์ iSCSI
บล็อก
ไฟล์แสดงด้วยบล็อกตั้งแต่หนึ่งบล็อกขึ้นไป แต่ละบล็อกจะถูกจัดเก็บไว้ในอุปกรณ์เสมือนหนึ่งเครื่อง ขนาดบล็อกมักจะเท่ากับพารามิเตอร์ บันทึกขนาดแต่สามารถลดขนาดลงมาได้ 2^กะหากมีข้อมูลเมตาหรือไฟล์ขนาดเล็ก
เราจริงๆ จริงๆ อย่าล้อเล่นกับบทลงโทษด้านประสิทธิภาพหากคุณตั้งกะเล็กน้อยเกินไป
ในพูล ZFS ข้อมูลทั้งหมด รวมถึงข้อมูลเมตา ถูกจัดเก็บไว้ในบล็อก ขนาดบล็อกสูงสุดสำหรับแต่ละชุดข้อมูลถูกกำหนดไว้ในคุณสมบัติ recordsize (ขนาดบันทึก). ขนาดบันทึกสามารถเปลี่ยนแปลงได้ แต่จะไม่เปลี่ยนขนาดหรือตำแหน่งของบล็อกใดๆ ที่เขียนลงในชุดข้อมูลแล้ว โดยจะส่งผลต่อบล็อกใหม่เมื่อเขียนเท่านั้น
ขนาดรายการเริ่มต้นปัจจุบันคือ 128 KiB เว้นแต่จะระบุไว้เป็นอย่างอื่น ถือเป็นการแลกเปลี่ยนที่ยากลำบากโดยที่ประสิทธิภาพจะไม่สมบูรณ์แบบ แต่ในกรณีส่วนใหญ่ก็จะไม่แย่นัก Recordsize สามารถตั้งค่าเป็นค่าใดก็ได้ตั้งแต่ 4K ถึง 1M (พร้อมการตั้งค่าเพิ่มเติม recordsize คุณสามารถติดตั้งเพิ่มเติมได้ แต่นี่ไม่ใช่ความคิดที่ดีเลย)
บล็อกใดก็ตามหมายถึงข้อมูลของไฟล์เดียว คุณไม่สามารถบีบไฟล์สองไฟล์ที่แตกต่างกันให้เป็นบล็อกเดียวได้ แต่ละไฟล์ประกอบด้วยหนึ่งหรือหลายบล็อก ขึ้นอยู่กับขนาดของมัน หากขนาดไฟล์เล็กกว่าขนาดบันทึก ไฟล์นั้นจะถูกจัดเก็บไว้ในบล็อกที่เล็กกว่า ตัวอย่างเช่น บล็อกที่มีไฟล์ 2 KiB จะใช้เซกเตอร์ 4 KiB เพียงเซกเตอร์บนดิสก์เท่านั้น
หากไฟล์มีขนาดใหญ่พอและต้องใช้หลายบล็อก บันทึกทั้งหมดที่มีไฟล์นี้จะมีขนาด recordsize - รวมถึงรายการสุดท้ายซึ่งส่วนหลักอาจเป็น .
วอลุ่ม zvol ไม่มีคุณสมบัติ recordsize - แทนที่จะมีคุณสมบัติเทียบเท่ากัน volblocksize.
ภาค
สิ่งสุดท้ายที่เป็นพื้นฐานที่สุดคือเซกเตอร์ เป็นหน่วยทางกายภาพที่เล็กที่สุดที่สามารถเขียนหรืออ่านได้จากอุปกรณ์พื้นฐาน เป็นเวลาหลายทศวรรษที่ดิสก์ส่วนใหญ่ใช้เซกเตอร์ขนาด 512 ไบต์ เมื่อเร็ว ๆ นี้ ดิสก์ส่วนใหญ่ได้รับการกำหนดค่าสำหรับเซกเตอร์ 4 KiB และบางส่วน - โดยเฉพาะ SSD - มีเซกเตอร์ 8 KiB หรือมากกว่านั้น
ZFS มีคุณสมบัติที่ให้คุณกำหนดขนาดเซกเตอร์ได้ด้วยตนเอง คุณสมบัตินี้ ashift. ค่อนข้างน่าสับสน ashift คือพลังของทั้งสอง ตัวอย่างเช่น, ashift=9 หมายถึงขนาดเซกเตอร์ 2^9 หรือ 512 ไบต์
ZFS สืบค้นระบบปฏิบัติการสำหรับข้อมูลโดยละเอียดเกี่ยวกับอุปกรณ์บล็อกแต่ละตัวเมื่อเพิ่มไปยัง vdev ใหม่ และในทางทฤษฎีจะติดตั้ง ashift โดยอัตโนมัติตามข้อมูลดังกล่าว น่าเสียดายที่ไดรฟ์จำนวนมากโกหกเกี่ยวกับขนาดเซกเตอร์เพื่อรักษาความเข้ากันได้กับ Windows XP (ซึ่งไม่สามารถเข้าใจไดรฟ์ที่มีขนาดเซกเตอร์อื่นได้)
ซึ่งหมายความว่าผู้ดูแลระบบ ZFS ควรทราบขนาดเซกเตอร์ที่แท้จริงของอุปกรณ์และตั้งค่าด้วยตนเอง ashift. หากตั้งค่า Ashift น้อยเกินไป จำนวนการดำเนินการอ่าน/เขียนจะเพิ่มขึ้นอย่างมาก ดังนั้น การเขียน "เซกเตอร์" ขนาด 512 ไบต์ลงในเซกเตอร์ 4 KiB จริงหมายถึงต้องเขียน "เซกเตอร์" แรก จากนั้นอ่านเซกเตอร์ 4 KiB แก้ไขด้วย "เซกเตอร์" ขนาด 512 ไบต์ที่สอง แล้วเขียนกลับไปเป็นเซกเตอร์ใหม่ 4 ภาค KiB และอื่นๆ สำหรับแต่ละรายการ
ในโลกแห่งความเป็นจริง บทลงโทษดังกล่าวส่งผลต่อ Samsung EVO SSD ซึ่งควรใช้ ashift=13แต่ SSD เหล่านี้มีขนาดเซกเตอร์ ดังนั้นค่าเริ่มต้นจึงตั้งไว้ที่ ashift=9. หากผู้ดูแลระบบที่มีประสบการณ์ไม่เปลี่ยนการตั้งค่านี้ แสดงว่า SSD นี้ใช้งานได้ ช้าลง HDD แม่เหล็กปกติ
สำหรับการเปรียบเทียบสำหรับขนาดที่ใหญ่เกินไป ashift ไม่มีการลงโทษในทางปฏิบัติ ไม่มีการปรับประสิทธิภาพจริง และการเพิ่มพื้นที่ที่ไม่ได้ใช้นั้นน้อยมาก (หรือเป็นศูนย์เมื่อเปิดใช้การบีบอัด) ดังนั้น เราขอแนะนำอย่างยิ่งให้ติดตั้งแม้แต่ไดรฟ์ที่ใช้เซกเตอร์ 512 ไบต์ ashift=12 หรือ ashift=13เพื่อเผชิญอนาคตอย่างมั่นใจ
คุณสมบัติ ashift ถูกตั้งค่าสำหรับอุปกรณ์เสมือน vdev แต่ละเครื่อง และ ไม่ใช่สำหรับสระว่ายน้ำอย่างที่หลายๆ คนคิดผิด - และไม่เปลี่ยนแปลงหลังการติดตั้ง หากเผลอชน. ashift เมื่อคุณเพิ่ม vdev ใหม่ลงในพูล คุณได้ทำให้พูลนั้นสกปรกอย่างไม่สามารถแก้ไขได้ด้วยอุปกรณ์ประสิทธิภาพต่ำ และโดยปกติแล้วจะไม่มีทางเลือกอื่นนอกจากทำลายพูลและเริ่มต้นใหม่ แม้แต่การลบ vdev ก็ไม่ได้ช่วยให้คุณรอดจากการกำหนดค่าที่เสียหายได้ ashift!
กลไกการคัดลอกเมื่อเขียน
หากระบบไฟล์ปกติจำเป็นต้องเขียนทับข้อมูล ระบบจะเปลี่ยนบล็อกแต่ละบล็อกที่อยู่
ระบบไฟล์ copy-on-write เขียนบล็อกเวอร์ชันใหม่แล้วปลดล็อกเวอร์ชันเก่า
ในเชิงนามธรรม หากเราเพิกเฉยต่อตำแหน่งทางกายภาพที่แท้จริงของบล็อก ดังนั้น "ดาวหางข้อมูล" ของเราจะถูกทำให้ง่ายขึ้นเป็น "หนอนข้อมูล" ที่เคลื่อนที่จากซ้ายไปขวาทั่วทั้งแผนที่ของพื้นที่ว่าง
ตอนนี้เราเข้าใจแล้วว่าสแน็ปช็อตแบบคัดลอกเมื่อเขียนทำงานอย่างไร แต่ละบล็อกสามารถเป็นของสแน็ปช็อตหลายรายการได้ และจะคงอยู่จนกว่าสแน็ปช็อตที่เกี่ยวข้องทั้งหมดจะถูกทำลาย
กลไก Copy on Write (CoW) เป็นพื้นฐานสำคัญของสิ่งที่ทำให้ ZFS เป็นระบบที่น่าทึ่ง แนวคิดพื้นฐานนั้นเรียบง่าย - หากคุณขอให้ระบบไฟล์แบบดั้งเดิมเปลี่ยนไฟล์ ระบบจะทำสิ่งที่คุณขอทุกประการ หากคุณขอให้ระบบไฟล์ copy-on-write ทำเช่นเดียวกัน ระบบจะบอกว่า "ตกลง" แต่เป็นการโกหกคุณ
แต่ระบบไฟล์แบบคัดลอกเมื่อเขียนจะเขียนเวอร์ชันใหม่ของบล็อกที่แก้ไข จากนั้นอัปเดตข้อมูลเมตาของไฟล์เพื่อยกเลิกการเชื่อมโยงบล็อกเก่าและเชื่อมโยงกับบล็อกใหม่ที่คุณเพิ่งเขียน
การยกเลิกการเชื่อมโยงบล็อกเก่าและการเชื่อมโยงบล็อกใหม่เสร็จสิ้นในการดำเนินการครั้งเดียว ดังนั้นจึงไม่สามารถถูกรบกวนได้ - หากคุณรีเซ็ตพลังงานหลังจากนี้เกิดขึ้น คุณจะมีไฟล์เวอร์ชันใหม่ และหากคุณรีเซ็ตพลังงานก่อนหน้านี้ แสดงว่าคุณมี รุ่นเก่า ไม่ว่าในกรณีใดจะไม่มีข้อขัดแย้งในระบบไฟล์
การคัดลอกเมื่อเขียนใน ZFS ไม่เพียงเกิดขึ้นในระดับระบบไฟล์เท่านั้น แต่ยังเกิดขึ้นในระดับการจัดการดิสก์ด้วย ซึ่งหมายความว่า ZFS ไม่ไวต่อช่องว่างในบันทึก () - ปรากฏการณ์ที่แถบถูกบันทึกเพียงบางส่วนก่อนที่ระบบจะพัง โดยสร้างความเสียหายให้กับอาเรย์หลังจากการรีบูต ที่นี่แถบถูกเขียนแบบอะตอมมิก vdev จะเป็นลำดับเสมอและ .
ZIL: บันทึกเจตนา ZFS
ระบบ ZFS ปฏิบัติต่อการเขียนแบบซิงโครนัสในลักษณะพิเศษ - เป็นการชั่วคราวแต่เก็บไว้ใน ZIL ก่อนที่จะเขียนอย่างถาวรในภายหลังพร้อมกับการเขียนแบบอะซิงโครนัส
โดยปกติแล้ว ข้อมูลที่เขียนไปยัง ZIL จะไม่ถูกอ่านอีก แต่สิ่งนี้เป็นไปได้หลังจากระบบล้มเหลว
SLOG หรืออุปกรณ์ LOG รองเป็นเพียง vdev ที่พิเศษและเร็วกว่ามากโดยที่ ZIL สามารถจัดเก็บแยกต่างหากจากที่เก็บข้อมูลหลัก
หลังจากเกิดความผิดพลาด ข้อมูลสกปรกทั้งหมดใน ZIL จะถูกเล่นซ้ำ - ในกรณีนี้ ZIL อยู่ใน SLOG ดังนั้นจึงเป็นที่ที่จะถูกเล่นซ้ำ
การดำเนินการเขียนมีสองประเภทหลัก - ซิงโครนัส (ซิงค์) และอะซิงโครนัส (อะซิงโครนัส) สำหรับปริมาณงานส่วนใหญ่ การเขียนส่วนใหญ่จะเป็นแบบอะซิงโครนัส - ระบบไฟล์ช่วยให้สามารถรวมและออกเป็นแบทช์ได้ ลดการกระจายตัวและเพิ่มปริมาณงานอย่างมาก
การบันทึกที่ซิงโครไนซ์เป็นเรื่องที่แตกต่างไปจากเดิมอย่างสิ้นเชิง เมื่อแอปพลิเคชันร้องขอการเขียนแบบซิงโครนัส ระบบจะบอกระบบไฟล์ว่า: "คุณต้องส่งสิ่งนี้ไปยังหน่วยความจำแบบไม่ลบเลือน ตอนนี้และจนถึงตอนนั้นฉันก็ทำอะไรไม่ได้อีกแล้ว” ดังนั้น การเขียนแบบซิงโครนัสจะต้องถูกคอมมิตบนดิสก์ทันที และหากสิ่งนี้เพิ่มการกระจายตัวหรือลดปริมาณงาน ก็ต้องเป็นเช่นนั้น
ZFS จัดการการเขียนแบบซิงโครนัสแตกต่างจากระบบไฟล์ทั่วไป แทนที่จะฟลัชการเขียนไปยังที่จัดเก็บข้อมูลปกติทันที ZFS จะส่งการเขียนไปยังพื้นที่จัดเก็บข้อมูลพิเศษที่เรียกว่า ZFS Intent Log หรือ ZIL เคล็ดลับก็คือว่าบันทึกเหล่านี้ ด้วย ยังคงอยู่ในหน่วยความจำ ถูกรวมเข้ากับคำขอเขียนแบบอะซิงโครนัสปกติ จะถูกล้างข้อมูลในภายหลังไปยังที่เก็บข้อมูลเป็น TXGs (กลุ่มธุรกรรม) ปกติอย่างสมบูรณ์
ในระหว่างการทำงานปกติ ZIL จะถูกเขียนและจะไม่อ่านอีก หลังจากนั้นครู่หนึ่ง บันทึกจาก ZIL ถูกส่งไปยังที่เก็บข้อมูลหลักใน TXG ปกติจาก RAM บันทึกเหล่านั้นจะถูกแยกออกจาก ZIL เวลาเดียวที่อ่านบางสิ่งจาก ZIL คือเมื่อนำเข้าพูล
หาก ZFS ล้มเหลว - ระบบปฏิบัติการขัดข้องหรือไฟฟ้าดับ - ขณะที่มีข้อมูลอยู่ใน ZIL ข้อมูลนั้นจะถูกอ่านระหว่างการนำเข้าพูลครั้งถัดไป (เช่น เมื่อระบบฉุกเฉินเริ่มทำงานใหม่) สิ่งใดก็ตามใน ZIL จะถูกอ่าน จัดกลุ่มเป็น TXG ผูกมัดกับพื้นที่จัดเก็บหลัก จากนั้นแยกออกจาก ZIL ในระหว่างกระบวนการนำเข้า
หนึ่งในคลาสตัวช่วย vdev เรียกว่า LOG หรือ SLOG ซึ่งเป็นอุปกรณ์รองของ LOG มันมีจุดประสงค์เดียว - เพื่อให้พูลมี vdev ที่ทนทานต่อการเขียนที่แยกจากกัน และเร็วกว่ามาก เพื่อจัดเก็บ ZIL แทนที่จะเก็บ ZIL บนที่เก็บ vdev หลัก ZIL เองจะทำงานเหมือนกันไม่ว่าจะเก็บไว้ที่ใด แต่ถ้า LOG vdev มีประสิทธิภาพการเขียนที่สูงมาก การเขียนแบบซิงโครนัสจะเร็วขึ้น
การเพิ่ม vdev ด้วย LOG ไปยังพูลไม่ทำงาน ไม่ได้ ปรับปรุงประสิทธิภาพการเขียนแบบอะซิงโครนัส - แม้ว่าคุณจะบังคับให้เขียนทั้งหมดไปยัง ZIL ด้วย zfs set sync=alwaysพวกเขาจะยังคงเชื่อมโยงกับที่เก็บข้อมูลหลักใน TXG ในลักษณะเดียวกันและในจังหวะเดียวกันโดยไม่มีการบันทึก การปรับปรุงประสิทธิภาพโดยตรงเพียงอย่างเดียวคือเวลาแฝงของการเขียนแบบซิงโครนัส (เนื่องจากบันทึกที่เร็วกว่าจะเพิ่มความเร็วในการดำเนินการ) sync).
อย่างไรก็ตาม ในสภาพแวดล้อมที่ต้องการการเขียนแบบซิงโครนัสจำนวนมากอยู่แล้ว vdev LOG สามารถเร่งความเร็วทางอ้อมในการเขียนแบบอะซิงโครนัสและการอ่านแบบไม่แคช การถ่ายรายการ ZIL ไปยัง vdev LOG แยกต่างหากหมายถึงความขัดแย้งน้อยลงสำหรับ IOPS บนที่เก็บข้อมูลหลัก ซึ่งช่วยปรับปรุงประสิทธิภาพของการอ่านและเขียนทั้งหมดในระดับหนึ่ง
ภาพรวม
กลไกการคัดลอกเมื่อเขียนยังเป็นพื้นฐานที่จำเป็นสำหรับ ZFS atomic snapshot และการจำลองแบบอะซิงโครนัสส่วนเพิ่ม ระบบไฟล์ที่ใช้งานอยู่มีแผนผังตัวชี้ที่ทำเครื่องหมายบันทึกทั้งหมดด้วยข้อมูลปัจจุบัน - เมื่อคุณถ่ายภาพ คุณเพียงแค่ทำสำเนาของแผนผังตัวชี้นี้
เมื่อบันทึกถูกเขียนทับบนระบบไฟล์ที่ใช้งานอยู่ อันดับแรก ZFS จะเขียนเวอร์ชันบล็อกใหม่ลงในพื้นที่ที่ไม่ได้ใช้ จากนั้นจะแยกบล็อกเวอร์ชันเก่าออกจากระบบไฟล์ปัจจุบัน แต่ถ้าสแน็ปช็อตบางส่วนอ้างถึงบล็อกเก่า ก็ยังคงไม่เปลี่ยนแปลง บล็อกเก่าจะไม่ถูกกู้คืนเป็นพื้นที่ว่างจริง ๆ จนกว่าสแน็ปช็อตทั้งหมดที่อ้างถึงบล็อกนี้จะถูกทำลาย!
การจำลองแบบ
คลัง Steam ของฉันในปี 2015 คือ 158 GiB และรวมไฟล์ 126 ไฟล์ นี่ค่อนข้างใกล้เคียงกับสถานการณ์ที่เหมาะสมที่สุดสำหรับ rsync - การจำลอง ZFS ผ่านเครือข่ายนั้นเร็วขึ้น "เพียง" เท่านั้น 927%
ในเครือข่ายเดียวกัน การจำลองไฟล์อิมเมจเครื่องเสมือน Windows 40 ขนาด 7GB ไฟล์เดียวเป็นเรื่องราวที่แตกต่างไปจากเดิมอย่างสิ้นเชิง การจำลองแบบ ZFS นั้นเร็วกว่า rsync ถึง 289 เท่า หรือเร็วกว่า "เท่านั้น" ถึง 161 เท่า หากคุณเข้าใจพอที่จะเรียก rsync ด้วย --inplace
เมื่ออิมเมจ VM ถูกปรับขนาด ปัญหา rsync จะปรับขนาดด้วย 1,9 TiB นั้นไม่ใหญ่สำหรับอิมเมจ VM สมัยใหม่ แต่มันใหญ่พอที่การจำลองแบบ ZFS จะเร็วกว่า rsync ถึง 1148 เท่า แม้จะใช้อาร์กิวเมนต์ --inplace ของ rsync
เมื่อคุณเข้าใจวิธีการทำงานของสแน็ปช็อตแล้ว คุณจะเข้าใจสาระสำคัญของการจำลองได้ง่าย เนื่องจากสแน็ปช็อตเป็นเพียงแผนผังของตัวชี้บันทึก ดังนั้นหากเราทำอย่างนั้น zfs send สแนปชอต จากนั้นเราจะส่งทั้งแผนผังนี้และบันทึกทั้งหมดที่เกี่ยวข้อง เมื่อเราส่งสิ่งนี้ zfs send в zfs receive บนเป้าหมาย จะเขียนทั้งเนื้อหาจริงของบล็อกและแผนผังของตัวชี้ที่อ้างถึงบล็อกไปยังชุดข้อมูลเป้าหมาย
สิ่งที่น่าสนใจยิ่งขึ้นในครั้งที่สอง zfs send. ตอนนี้เรามีสองระบบ แต่ละระบบประกอบด้วย poolname/datasetname@1และคุณถ่ายภาพใหม่ poolname/datasetname@2. ดังนั้นในสระเดิมที่คุณมี datasetname@1 и datasetname@2และในกลุ่มเป้าหมายจนถึงขณะนี้มีเพียงสแน็ปช็อตแรกเท่านั้น datasetname@1.
เพราะระหว่างแหล่งที่มาและเป้าหมายเรามีภาพรวมร่วมกัน datasetname@1, เราทำได้ เพิ่มขึ้น zfs send มากกว่านั้น เมื่อเราบอกกับระบบ zfs send -i poolname/datasetname@1 poolname/datasetname@2มันเปรียบเทียบต้นไม้พอยน์เตอร์สองตัว พอยน์เตอร์ใดๆ ที่มีเฉพาะใน @2เห็นได้ชัดว่าหมายถึงบล็อกใหม่ - ดังนั้นเราจึงต้องการเนื้อหาของบล็อกเหล่านี้
บนระบบรีโมต ประมวลผลส่วนเพิ่ม send ง่ายเหมือนกัน ก่อนอื่น เราเขียนรายการใหม่ทั้งหมดที่รวมอยู่ในสตรีม sendแล้วเพิ่มตัวชี้ลงในบล็อกเหล่านั้น Voila เรามี @2 ในระบบใหม่!
ZFS asynchronous incremental replication เป็นการปรับปรุงครั้งใหญ่เหนือวิธีการที่ไม่ใช่สแน็ปช็อตก่อนหน้านี้ เช่น rsync ในทั้งสองกรณี เฉพาะข้อมูลที่เปลี่ยนแปลงเท่านั้นที่จะถูกถ่ายโอน - แต่ต้อง rsync ก่อน อ่าน จากดิสก์ข้อมูลทั้งหมดทั้งสองด้านเพื่อตรวจสอบผลรวมและเปรียบเทียบ ในทางตรงกันข้าม การจำลองแบบ ZFS จะไม่อ่านอะไรเลยนอกจากพอยน์เตอร์ทรี - และบล็อกใดๆ ที่ไม่มีอยู่ในสแน็ปช็อตที่ใช้ร่วมกัน
การบีบอัดในตัว
กลไกการคัดลอกเมื่อเขียนยังช่วยลดความยุ่งยากของระบบการบีบอัดแบบอินไลน์ ในระบบไฟล์แบบดั้งเดิม การบีบอัดเป็นปัญหา - ทั้งเวอร์ชันเก่าและเวอร์ชันใหม่ของข้อมูลที่แก้ไขจะอยู่ในพื้นที่เดียวกัน
หากเราพิจารณาข้อมูลชิ้นหนึ่งที่อยู่ตรงกลางไฟล์ที่เริ่มต้นชีวิตเป็นเมกะไบต์ของศูนย์ตั้งแต่ 0x00000000 เป็นต้นไป การบีบอัดให้เป็นหนึ่งเซกเตอร์บนดิสก์นั้นง่ายมาก แต่จะเกิดอะไรขึ้นหากเราแทนที่เมกะไบต์ของศูนย์นั้นด้วยเมกะไบต์ของข้อมูลที่บีบอัดไม่ได้ เช่น JPEG หรือสัญญาณรบกวนแบบสุ่มหลอก โดยไม่คาดคิดข้อมูลเมกะไบต์นี้จะไม่ต้องการหนึ่งส่วน แต่ 256 4 KiB เซ็กเตอร์และในที่นี้สงวนไว้เพียงเซกเตอร์เดียวบนดิสก์
ZFS ไม่มีปัญหานี้ เนื่องจากบันทึกที่แก้ไขจะถูกเขียนไปยังพื้นที่ที่ไม่ได้ใช้เสมอ - บล็อกเดิมใช้เซกเตอร์ 4 KiB เพียงเซกเตอร์เดียว และเร็กคอร์ดใหม่จะใช้ 256 แต่นี่ไม่ใช่ปัญหา - แฟรกเมนต์ที่แก้ไขล่าสุดจาก " ตรงกลาง" ของไฟล์จะถูกเขียนไปยังพื้นที่ที่ไม่ได้ใช้งาน โดยไม่คำนึงว่าขนาดของไฟล์จะเปลี่ยนไปหรือไม่ ดังนั้นสำหรับ ZFS นี่จึงเป็นเรื่องปกติ
การบีบอัด ZFS ในตัวจะถูกปิดใช้งานตามค่าเริ่มต้น และระบบมีอัลกอริธึมแบบเสียบได้ - ปัจจุบันประกอบด้วย LZ4, gzip (1-9), LZJB และ ZLE
- LZ4 เป็นอัลกอริทึมการสตรีมที่ให้การบีบอัดและคลายการบีบอัดที่รวดเร็วเป็นพิเศษ และประโยชน์ด้านประสิทธิภาพสำหรับกรณีการใช้งานส่วนใหญ่ - แม้แต่ใน CPU ที่ค่อนข้างช้า
- GZIP เป็นอัลกอริทึมที่น่าเคารพซึ่งผู้ใช้ Unix ทุกคนรู้จักและชื่นชอบ สามารถนำไปใช้กับการบีบอัดระดับ 1-9 โดยอัตราส่วนการบีบอัดและการใช้งาน CPU จะเพิ่มขึ้นเมื่อเข้าใกล้ระดับ 9 อัลกอริทึมนี้เหมาะสำหรับกรณีการใช้งานข้อความ (หรือการบีบอัดสูงอื่นๆ) แต่อย่างอื่นมักจะทำให้เกิดปัญหากับ CPU - ใช้มัน ด้วยความระมัดระวังโดยเฉพาะในระดับที่สูงขึ้น
- แอลซีเจบี เป็นอัลกอริทึมดั้งเดิมใน ZFS มันล้าสมัยและไม่ควรใช้อีกต่อไป LZ4 เหนือกว่าในทุกด้าน
- ZLE - การเข้ารหัสระดับศูนย์, การเข้ารหัสระดับศูนย์ มันไม่ได้แตะต้องข้อมูลปกติเลย แต่บีบอัดลำดับเลขศูนย์จำนวนมาก มีประโยชน์สำหรับชุดข้อมูลที่ไม่สามารถบีบอัดได้อย่างสมบูรณ์ (เช่น JPEG, MP4 หรือรูปแบบอื่นๆ ที่บีบอัดแล้ว) เนื่องจากจะละเว้นข้อมูลที่บีบอัดไม่ได้ แต่จะบีบอัดพื้นที่ที่ไม่ได้ใช้ในบันทึกผลลัพธ์
เราขอแนะนำการบีบอัด LZ4 สำหรับกรณีการใช้งานเกือบทั้งหมด การปรับประสิทธิภาพเมื่อพบกับข้อมูลที่บีบอัดไม่ได้นั้นน้อยมาก และ การเจริญเติบโต ประสิทธิภาพสำหรับข้อมูลทั่วไปมีความสำคัญ การคัดลอกอิมเมจเครื่องเสมือนสำหรับการติดตั้งระบบปฏิบัติการ Windows ใหม่ (ระบบปฏิบัติการที่ติดตั้งใหม่ยังไม่มีข้อมูลภายใน) ด้วย compression=lz4 ผ่านเร็วกว่าด้วย 27% compression=noneใน .
ARC - แคชแทนที่แบบปรับได้
ZFS เป็นระบบไฟล์สมัยใหม่เพียงระบบเดียวที่เรารู้จักซึ่งใช้กลไกการอ่านแคชของตัวเอง แทนที่จะอาศัยแคชเพจของระบบปฏิบัติการเพื่อเก็บสำเนาของบล็อกที่เพิ่งอ่านใน RAM
แม้ว่าแคชดั้งเดิมจะไม่มีปัญหา แต่ ZFS ไม่สามารถตอบสนองต่อคำขอการจัดสรรหน่วยความจำใหม่ได้เร็วเท่ากับเคอร์เนล ดังนั้นการโทรใหม่ malloc() ในการจัดสรรหน่วยความจำอาจล้มเหลวหากต้องการ RAM ที่ ARC ครอบครองอยู่ในปัจจุบัน แต่มีเหตุผลที่ดีในการใช้แคชของคุณเอง อย่างน้อยก็ในตอนนี้
ระบบปฏิบัติการสมัยใหม่ที่รู้จักทั้งหมด รวมถึง MacOS, Windows, Linux และ BSD ใช้อัลกอริทึม LRU (ใช้ล่าสุดน้อยที่สุด) เพื่อใช้แคชของเพจ นี่เป็นอัลกอริทึมดั้งเดิมที่ดันบล็อกแคช "ขึ้นคิว" หลังจากอ่านแต่ละครั้ง และผลักบล็อก "ลงคิว" ตามความจำเป็นเพื่อเพิ่มแคชที่พลาดไปใหม่ (บล็อกที่ควรอ่านจากดิสก์ ไม่ใช่จากแคช) ขึ้น.
โดยปกติแล้วอัลกอริธึมจะทำงานได้ดี แต่ในระบบที่มีชุดข้อมูลการทำงานขนาดใหญ่ LRU นำไปสู่การทำลายล้างได้อย่างง่ายดาย โดยกำจัดบล็อกที่จำเป็นบ่อยครั้งเพื่อให้มีที่ว่างสำหรับบล็อกที่จะไม่ถูกอ่านจากแคชอีกเลย
เป็นอัลกอริธึมที่ไร้เดียงสาน้อยกว่ามากซึ่งถือได้ว่าเป็นแคช "ถ่วงน้ำหนัก" ทุกครั้งที่อ่านบล็อกแคช บล็อกจะหนักขึ้นเล็กน้อยและยากต่อการไล่ออก - และแม้กระทั่งหลังจากที่บล็อกถูกไล่ออกแล้ว ติดตาม ภายในระยะเวลาหนึ่ง บล็อกที่ถูกไล่ออกแต่จำเป็นต้องอ่านกลับเข้าไปในแคชก็จะ "หนักขึ้น" เช่นกัน
ผลลัพธ์สุดท้ายของทั้งหมดนี้คือแคชที่มีอัตราส่วนการเข้าถึงที่สูงกว่ามาก อัตราส่วนระหว่างการเข้าถึงแคช (อ่านจากแคช) และแคชหายไป (อ่านจากดิสก์) นี่เป็นสถิติที่สำคัญอย่างยิ่ง - ไม่เพียงแต่แคชที่เข้าถึงได้เองจะได้รับบริการตามลำดับความสำคัญที่เร็วขึ้นเท่านั้น แคชที่หายไปยังสามารถให้บริการได้เร็วขึ้น เนื่องจากยิ่งมีการเข้าถึงแคชมาก คำขอดิสก์พร้อมกันก็จะน้อยลง และเวลาแฝงที่ลดลงสำหรับการพลาดที่เหลือที่ต้อง เสิร์ฟพร้อมดิสก์
ข้อสรุป
หลังจากเรียนรู้ความหมายพื้นฐานของ ZFS - วิธีการทำงานของ copy-on-write ตลอดจนความสัมพันธ์ระหว่างพูลหน่วยเก็บข้อมูล อุปกรณ์เสมือน บล็อก เซ็กเตอร์ และไฟล์ เราพร้อมที่จะพูดคุยเกี่ยวกับประสิทธิภาพในโลกแห่งความเป็นจริงด้วยจำนวนจริง
ในส่วนถัดไป เราจะดูประสิทธิภาพที่แท้จริงของพูลที่มี vdevs แบบมิเรอร์และ RAIDz เปรียบเทียบกัน และยังเทียบกับโทโพโลยี RAID ของเคอร์เนล Linux แบบดั้งเดิมที่เราสำรวจด้วย .
ในตอนแรก เราต้องการครอบคลุมเฉพาะพื้นฐาน - โทโพโลยี ZFS เอง - แต่หลังจากนั้น เช่น เรามาเตรียมพร้อมที่จะพูดคุยเกี่ยวกับการตั้งค่าขั้นสูงและการปรับแต่ง ZFS รวมถึงการใช้ประเภท vdev เสริม เช่น L2ARC, SLOG และการจัดสรรพิเศษ
ที่มา: will.com