ZFS 2.3 เปิดตัว พร้อมฟีเจอร์ขยาย RAIDZ

 (github.com/openzfs)
1 คะแนน โดย GN⁺ 2025-01-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • OpenZFS 2.3.0 มีฟีเจอร์หลักคือ RAIDZ Expansion ซึ่งเพิ่มอุปกรณ์ใหม่เข้าไปในพูล RAIDZ ที่มีอยู่เดิม เพื่อเพิ่มความจุได้โดย ไม่ต้องหยุดให้บริการ
  • Fast Dedup ปรับปรุงประสิทธิภาพของฟีเจอร์ deduplication เดิมอย่างมาก และยังมีการปรับปรุงประสิทธิภาพทั่วทั้งโค้ดเบสด้วย
  • Direct IO ทำให้สามารถข้าม ARC ในการอ่าน/เขียนได้ มุ่งเป้าไปที่สภาพแวดล้อมอย่างอุปกรณ์ NVMe ที่การแคชอาจลดประสิทธิภาพลง
  • เพิ่ม เอาต์พุต JSON แบบเลือกใช้ได้สำหรับคำสั่งที่ใช้บ่อย, รองรับชื่อไฟล์และไดเรกทอรีได้สูงสุด 1023 อักขระ, และแก้บั๊กสำคัญที่จัดการปัญหาจากเวอร์ชันก่อนหน้า
  • ขอบเขตการรองรับคือ Linux kernel 4.18~6.12 และ FreeBSD 13.3, 14.0~14.2 โดยรอบการออกเวอร์ชันนี้มีผู้มีส่วนร่วม 134 คน

สิ่งที่เปลี่ยนไปใน OpenZFS 2.3.0

  • OpenZFS 2.3.0 อัปเดตโดยเน้นที่การขยายพื้นที่จัดเก็บ, ประสิทธิภาพของ deduplication, เส้นทาง I/O, รูปแบบเอาต์พุตของคำสั่ง และการรองรับความยาวชื่อไฟล์
  • แท็กรีลีสคือ zfs-2.3.0 และรวมการเปลี่ยนแปลงตั้งแต่ OpenZFS 2.2.0

การขยายพื้นที่จัดเก็บและการปรับปรุงประสิทธิภาพ

  • RAIDZ Expansion ทำให้สามารถเพิ่มอุปกรณ์ใหม่เข้าไปใน พูล RAIDZ ที่มีอยู่เดิม เพื่อเพิ่มความจุของพื้นที่จัดเก็บได้โดยไม่ต้องหยุดให้บริการ
  • Fast Dedup เป็นการอัปเกรดประสิทธิภาพหลักของฟีเจอร์ deduplication เดิมใน OpenZFS
  • Direct IO อนุญาตให้ ข้าม ARC ในการอ่าน/เขียนได้
    • มุ่งปรับปรุงประสิทธิภาพในสถานการณ์ที่การแคชอาจขัดขวางประสิทธิภาพ เช่น อุปกรณ์ NVMe
  • ยังมีการปรับปรุงประสิทธิภาพหลายรายการทั่วทั้งโค้ดเบสด้วย

เอาต์พุตคำสั่งและความยาวชื่อ

  • JSON เพิ่ม เอาต์พุต JSON แบบเลือกใช้ได้ให้กับคำสั่งที่ใช้บ่อยที่สุด
  • Long names รองรับชื่อไฟล์และไดเรกทอรีได้สูงสุด 1023 อักขระ

เสถียรภาพ แพลตฟอร์ม และการมีส่วนร่วม

  • รวม การแก้บั๊กสำคัญ ที่จัดการปัญหาที่รายงานในเวอร์ชันก่อนหน้า
  • แพลตฟอร์มที่รองรับ:
    • Linux kernel 4.18~6.12
    • FreeBSD 13.3, 14.0~14.2
  • รอบการออกเวอร์ชันนี้มีผู้มีส่วนร่วม 134 คน

เอกสารและบันทึกการเปลี่ยนแปลง

  • สามารถดูเอกสารสำหรับ Linux และ FreeBSD ได้ที่ OpenZFS documentation
  • Complete v2.2.0 - v2.3.0 change log ให้บันทึกการเปลี่ยนแปลงทั้งหมดตั้งแต่ OpenZFS 2.2.0 ถึง 2.3.0

การเปลี่ยนแปลงตัวเลือกโมดูล

  • ตัวเลือกทั้งหมดและสิ่งที่ควบคุมถูกสรุปไว้ในเอกสาร module parameters
  • ตัวเลือกโมดูลใหม่มีรายการที่เกี่ยวข้องกับ RAIDZ expansion, deduplication log, Direct IO, allocator, scrub และ resilver
    • ตัวอย่าง: raidz_expand_max_copy_bytes, raidz_expand_max_reflow_bytes, zfs_dio_enabled, zfs_dedup_log_mem_max, zfs_scrub_after_expand
  • ตัวเลือกโมดูลที่ถูกลบ:
    • zfetch_array_rd_sz
  • ตัวเลือกโมดูลที่เปลี่ยนแปลง:
    • zfs_arc_shrinker_limit
    • zfs_bclone_enabled
    • zfs_vdev_disk_classic
    • zio_taskq_write

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-01-15
ความคิดเห็นจาก Hacker News

  • การขยาย ZFS RAIDZ ที่เตรียมกันมาหลายปี ในที่สุดก็ถูกรวมเข้ามาแล้ว
    ฟีเจอร์หลัก ๆ คือการขยาย RAIDZ ที่เพิ่มอุปกรณ์เข้าไปในพูล RAIDZ เดิมเพื่อเพิ่มความจุโดยไม่ต้องหยุดระบบ, การ deduplication แบบเร็วที่ยกระดับประสิทธิภาพการลบข้อมูลซ้ำของ OpenZFS อย่างมาก, direct I/O ที่ข้าม ARC เพื่อปรับปรุงประสิทธิภาพในสภาพแวดล้อมที่แคชอาจไม่มีประสิทธิภาพนัก เช่น NVMe, การเลือกให้คำสั่งที่ใช้บ่อยบางคำสั่งส่งออกเป็น JSON ได้, และการรองรับชื่อไฟล์/ไดเรกทอรียาวสูงสุด 1023 อักขระ

    • ถ้าพูดให้แม่นยำกว่านั้น หมายถึงสามารถเพิ่มอุปกรณ์ใหม่ หรือก็คือดิสก์ เข้าไปใน RAIDZ vdev เดิมได้
    • ถ้ารัน Proxmox บน ZFS และ NVMe อยู่ ก็สงสัยว่าเมื่อ 2.3 ถูกปล่อยมาแล้วควรเปิด direct I/O หรือไม่
      อยากรู้ว่าฟีเจอร์นี้เหมาะกับการใช้งานแบบไหน
    • 4 รายการแรกดูเป็นการเปลี่ยนแปลงครั้งใหญ่มากจริง ๆ
    • แต่ก็น่าจะถือว่า การลบ vdev ยังทำไม่ได้อยู่ดี
    • สงสัยว่าฟีเจอร์นี้ถูกทดสอบร่วมกับ การเข้ารหัส ดีแค่ไหน
      และก็ยังสงสัยด้วยว่าทีม ZFS มองการเข้ารหัสเป็นเรื่องสำคัญระดับแรกจริงหรือไม่
      ZFS บน Linux ได้รับชื่อเสียงจาก ZFS บน Solaris มามาก แต่คนที่ใช้ในสภาพแวดล้อมโปรดักชัน หากอยากเห็นความเป็นจริงก็ควรดู issue tracker ให้ค่อนข้างละเอียด

  • ไม่เข้าใจว่าทำไมฝั่ง Windows ซึ่งเป็นแพลตฟอร์ม PC ที่ใหญ่ที่สุดอย่างท่วมท้นเมื่อวัดจากจำนวนผู้ใช้ ถึงยังไม่มี คำตอบสำหรับ ZFS
    Microsoft เคยมี WinFS แล้วต่อมาก็มี ReFS แต่ก็ถูกดันไปอยู่ข้างหลัง แม้การพัฒนายังดำเนินต่อไปและบางส่วนก็เข้ามาใน Win11 เป็นครั้งคราว แต่ก็ยังไม่เห็นการปล่อยเวอร์ชันทางการ
    มีบุคคลบางกลุ่มพยายามทำงานใหญ่ในการสร้างเลเยอร์ที่เข้ากันได้กับ ZFS แต่ยังห่างไกลจากระดับที่สุกงอมหรือใช้งานจริงได้
    ไม่รู้ว่า Windows ยังใช้ไฟล์ซิสเต็มอายุ 32 ปีอยู่ได้อย่างไร

    • พูดตามตรง สถานการณ์ของ Linux ก็ไม่ได้ดีกว่ากันมากนัก
      ZFS มี ปัญหาเรื่องไลเซนส์ กับ Linux ทำให้ไม่สามารถรวมเข้าด้วยกันได้อย่างสมบูรณ์ และ Btrfs แม้จะพัฒนามา 15 ปีแล้ว แต่ทั้งฟีเจอร์และความเสถียรก็ยังไม่ถึงระดับ ZFS
      ดิสโทร Linux ส่วนใหญ่ยังใช้ ext4 อายุ 19 ปีเป็นค่าเริ่มต้น และจริง ๆ แล้ว ext4 ก็ใกล้เคียงกับการเอาส่วนขยายไปวางบน ext2 ซึ่งมีอายุพอ ๆ กับ NTFS
      ถ้ามองอย่างเป็นธรรม องค์ประกอบของระบบปฏิบัติการที่สำคัญเท่าไฟล์ซิสเต็มนั้นมีไม่มาก และก็มีคนจำนวนมากที่ไม่อยากแตะไฟล์ซิสเต็มที่ยังไม่ผ่านการพิสูจน์ในสภาพแวดล้อมโปรดักชันมานานกว่า 10 ปี
    • เหตุผลง่ายมาก เพราะภาระส่วนใหญ่ที่ไฟล์ซิสเต็มควรต้องแบกรับ ถูก ฮาร์ดแวร์สตอเรจระดับองค์กร ที่วางไฟล์ซิสเต็มนั้นไว้รับไปแทน
      ฟังก์ชันที่จำเป็นอย่าง snapshot, deduplication ระดับบล็อก, เทคโนโลยี object storage, RAID/ความทนทาน, การปรับขนาด ฯลฯ ถูกอุปกรณ์สตอเรจรับหน้าที่ไป
      สตอเรจ appliance สมัยใหม่แทบจะเหมือนมนตร์ดำ จึงไม่จำเป็นต้องเพิ่มฟีเจอร์ให้ NTFS มากนัก
      แค่เข้าถึงผ่าน NAS/SAN แบบโปร่งใส หรือเก็บโวลุ่ม NTFS ไว้บนกล่องดิสก์ที่มีความสามารถก็พอ
      ในโลก Linux ระดับสูงมี Lustre และ GPFS ส่วน ZFS โดยทั่วไปเหมาะกับงานที่ประสิทธิภาพไม่ใช่หัวใจหลัก แต่ต้องการความทนทาน
    • ในเคอร์เนล Linux mainline ก็ไม่มีคำตอบที่เทียบเท่า ZFS เช่นกัน
      คิดว่าเพราะมันยากและมีความเสี่ยงสูง แต่ผลตอบแทนส่วนใหญ่ก็มีแค่การได้รับความเคารพทางเทคนิคเท่านั้น
    • ในฐานะผู้ใช้ปลายทางที่ใช้ Windows และ Linux แต่ไม่ได้ใช้ ZFS ก็สงสัยว่าตัวเองพลาดอะไรไป
    • OpenZFS สำหรับ Windows มาถึงสถานะ release candidate แล้ว (rc11) และยังมีบั๊กเหลืออยู่เล็กน้อยบริเวณการเมานต์โวลุ่ม
      ไม่ได้ร้ายแรง แต่ตอนนี้ควรหลีกเลี่ยงการเข้ารหัสไว้ก่อน และความเร็วในการพัฒนาก็สูงถึงขั้นมี release candidate ใหม่ออกมาทุกไม่กี่สัปดาห์เพื่อแก้ปัญหาที่เหลือ
      ถ้านำ Storage Spaces มาผสมด้วย เพื่อพูลดิสก์ที่ชนิดหรือขนาดต่างกัน และกำหนดตำแหน่ง·ความซ้ำซ้อน·การจัดชั้นแยกตามแต่ละ Space ได้ ตอนนี้ Windows ก็กลายเป็น แพลตฟอร์มสตอเรจขั้นสูง แล้ว
      หากใช้ Windows Server เช่น 2022/2025 Essentials ราคาย่อมเยา ก็สามารถใช้ SMB Direct/RDMA ที่มีประสิทธิภาพสูงสุด 10Gbyte/s บน LAN และดิสก์เสมือน .vhdx ได้ด้วย จึงเป็นทางเลือกที่เร็วกว่า iSCSI และแทบไม่ต้องตั้งค่า
      ดังนั้นจึงพอร์ต napp-it cs ซึ่งเป็นเว็บ GUI สำหรับ ZFS จาก Solaris ไปยัง Windows เพื่อให้จัดการ Storage Spaces, ZFS และเซิร์ฟเวอร์ OpenZFS ระยะไกลอย่าง Proxmox ได้ และใช้ฟรีสำหรับการใช้งานที่ไม่ใช่เชิงพาณิชย์

  • ชอบที่ทำฟีเจอร์ขยายนี้ออกมาค่อนข้างระมัดระวัง
    การขยายไม่เพียงโปร่งใสทั้งหมดและสามารถทำต่อได้ แต่ยังรักษา redundancy ไว้ตลอดกระบวนการด้วย
    อย่างไรก็ตามมีข้อสังเกตเล็ก ๆ อย่างหนึ่งที่ผู้คนควรรู้ไว้
    แม้หลังขยายเสร็จแล้ว บล็อกเดิมก็ยังคงอัตราส่วนข้อมูลต่อพาริตีแบบเดิมอยู่ ตัวอย่างเช่น RAIDZ2 แบบ 5-wide จะถูกกระจายอยู่บนชุดดิสก์ที่ใหญ่ขึ้นในสภาพข้อมูล 3 ส่วนต่อพาริตี 2 ส่วน
    บล็อกใหม่จะถูกเขียนด้วยอัตราส่วนข้อมูลต่อพาริตีแบบใหม่ ตัวอย่างเช่น ถ้าขยาย RAIDZ2 แบบ 5-wide หนึ่งครั้งจนกลายเป็น 6-wide ก็จะเป็นข้อมูล 4 ส่วนต่อพาริตี 2 ส่วน

    • ไม่แน่ใจจริง ๆ ว่านั่นนับเป็นข้อสังเกตหรือเปล่า มันแค่หมายความว่าข้อมูลเดิมอาจคงอยู่ในรูปแบบการจัดวางที่ไม่เหมาะที่สุด
      ถึงอย่างนั้นประโยชน์ของ RAIDZ N ก็ยังเหมือนเดิม คือแม้ดิสก์เสียหายทั้งลูกได้สูงสุด N ลูก พูลก็ยังทำงานต่อได้
    • ข้อสังเกตนั้นเป็นพฤติกรรมที่คาดเดาได้อยู่แล้ว ฟีเจอร์ของ ZFS โดยทั่วไปควรมองว่า จะไม่เขียนบล็อกเดิมใหม่
      เช่น การเปลี่ยนการตั้งค่าก็มีผลเฉพาะกับข้อมูลใหม่เท่านั้น
    • พูดตรง ๆ นี่เป็นข้อสังเกตที่ค่อนข้างใหญ่
      Da1 Db1 Dc1 Pa1 Pb1
      Da2 Db2 Dc2 Pa2 Pb2
      Da3 Db3 Dc3 Pa3 Pb3
      ___ ___ ___ Pa4 Pb4
      ตรงนี้ ___ คือพื้นที่ว่าง ถ้าเพิ่มดิสก์หนึ่งลูกเพื่อขยาย ตามตรรกะแล้วอาจคาดว่าจะได้แบบนี้
      Da1 Db1 Dc1 Da2 Pa1 Pb1
      Db2 Dc2 Da3 Db3 Pa2 Pb2
      Dc3 ___ ___ ___ Pa3 Pb3
      ___ ___ ___ ___ Pa4 Pb4
      แต่เท่าที่ผมเข้าใจ จริง ๆ แล้วมันขยายเป็นแบบนี้
      Da1 Db1 Dc1 Dd1 Pa1 Pb1
      Da2 Db2 Dc2 Dd2 Pa2 Pb2
      Da3 Db3 Dc3 Dd3 Pa3 Pb3
      ___ ___ ___ ___ Pa4 Pb4
      โดยบล็อก Dd1~3 ตรงนี้ถูกทิ้งเปล่าไปเฉย ๆ นั่นหมายความว่า แม้จะเพิ่มดิสก์ใหม่เข้าไปในอาร์เรย์ พื้นที่เก็บข้อมูลว่างก็เพิ่มขึ้นแค่ 25%
      ตัวอย่างเช่น ถ้าเดิมมีพื้นที่ใช้งานได้รวม 24TB จากดิสก์ 8TB และก่อนขยายเหลือพื้นที่ว่าง 4TB หลังขยายแล้วพื้นที่ว่างจะกลายเป็น 5TB
      หวังว่าจะมีคนบอกว่าผมเข้าใจผิด ถ้าไม่ได้เข้าใจผิด ก็ดูเป็นการใช้งานที่แทบไม่มีประโยชน์เลย

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

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

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

  • ในที่สุด!
    ตอนนี้แม้แต่ การจัดวาง vdev เดี่ยว แบบสุดโต่งก้ำกึ่งบ้าคลั่งอย่าง RAID-Z3 ด้วยฮาร์ดดิสก์ 4 ลูกที่แพงที่สุดและความหนาแน่นสูงที่สุดที่ซื้อได้ ก็เป็นไปได้แล้ว
    ช่วงแรกจะมี redundancy เท่ากับดิสก์ 3 ลูก ทำให้ใช้พื้นที่ได้จริงแค่ 25% แต่ทุกครั้งที่ความต้องการพื้นที่เพิ่มขึ้น ก็ซื้อดิสก์เพิ่มทีละลูกแล้วขยายไปจนราว ๆ 12 ลูกได้
    เมื่อเวลาผ่านไปราคาดิสก์จะลดลง และเพราะเพิ่มดิสก์คนละช่วงเวลา ความน่าจะเป็นที่จะเสียก็ถูกกระจายออกไปด้วย

    • ถูก แต่ควรดูคอมเมนต์พี่น้องด้วย
      ต่อให้ขยายอาร์เรย์ ข้อมูลเดิมก็ไม่ได้ถูกจัดเก็บอย่างมีประสิทธิภาพขึ้น
      ถ้าต้องการอัตราส่วนพาริตี/ข้อมูลแบบใหม่ ต้องบังคับคัดลอกข้อมูลแล้วลบเวอร์ชันเก่าที่ไม่มีประสิทธิภาพออก เช่น ต้องใช้เครื่องมือแบบนี้ [1]
      ส่วนตัวผมคิดว่าการซื้อชุด RAID-Z ที่สมบูรณ์แยกเป็นชุด ๆ แล้วเพิ่มชุดใหม่เข้าไป หรือค่อย ๆ เปลี่ยนชุดเก่าแบบดิสก์ต่อดิสก์ เป็นทางเลือกที่ดีกว่ามาก
      [1] https://github.com/markusressel/zfs-inplace-rebalancing

  • สงสัยว่า ZFS เมื่อเทียบกับ btrfs แล้วเป็นอย่างไร
    ตอนนี้ใช้ btrfs บนโฮมเซิร์ฟเวอร์อยู่ แต่เจอปัญหาแปลก ๆ มาหลายครั้ง
    กำลังคิดจะย้ายไป ZFS แต่ก็ไม่อยากตกอยู่ในสถานการณ์แบบเดิม

    • เคยลองใช้ btrfs ครั้งแรกเมื่อราว 15 ปีก่อน ช่วง Linux 2.6.33-rc4
      ภายใน 3 วันก็มีไฟล์ที่ลบไม่ได้เกิดขึ้น เลยหยุดใช้ แล้วภายหลังก็ไปเจอ ZFS
      ZFS เองก็มีปัญหาที่รุนแรงน้อยกว่าบางอย่าง แต่ตอนนั้นเป็นนักศึกษาวิทยาการคอมพิวเตอร์ และเมื่อเทียบกับปัญหาที่เจอใน btrfs แล้วมันดูเล็กน้อย จึงคิดว่าน่าจะแก้ได้
      หลังจากนั้นตลอด 18 เดือน ก็แก้ปัญหาที่กวนใจทั้งหมดและส่งแพตช์ไปยังที่เก็บ ZFSOnLinux ในตอนนั้น ซึ่งความพยายามนั้นช่วยให้ ZFS บน Linux ใช้งานในสภาพแวดล้อมจริงได้
      จากนั้นก็ใช้ ZFS มาตลอด และมันก็ทำงานได้ดี
      ถ้าสถานะของ btrfs ดีกว่านี้ ก็คงได้กลายเป็นผู้ร่วมพัฒนา btrfs ไปแล้ว แต่ไม่ใช่แค่ตอนนั้นสถานะแย่เท่านั้น หลังจากนั้นทุกครั้งที่ลองใช้กับงานจริงจังก็ยังโดนปัญหาอย่าง ENOSPC โผล่บ่อย ๆ ทั้งที่ยังมีพื้นที่เหลืออยู่คอยขัดขา
      ในทางกลับกัน ZFS ก็แค่ทำงานได้ตามปกติ ผมและอีกหลายคนทุ่มงานจำนวนมากเพื่อให้มันทำงานได้ดี
      ความแตกต่างที่ใหญ่ที่สุดคือ ZFS มีรากฐานที่แข็งแกร่งมาก และนั่นเป็นผลจากระบบ การทดสอบ regression ที่ยอดเยี่ยม
      เวอร์ชันใน user space จะรันโค้ดแบบสุ่มเพื่อหา bug ก่อนที่มันจะไประเบิดในสภาพแวดล้อมจริง และทุกการเปลี่ยนแปลงที่เสนอเข้ามาจะรันชุดทดสอบเพื่อคัดกรอง bug
      ZFS ยังมีคนตรวจสอบการเปลี่ยนแปลงที่เสนอมากกว่าไฟล์ซิสเต็มอื่น ๆ ด้วย นักพัฒนา Btrfs เองก็มักพูดว่าจำนวนคนระหว่างสองไฟล์ซิสเต็มนี้ต่างกันมาก จำได้คร่าว ๆ ว่าต่างกันประมาณ 6 เท่า
      อย่างไรก็ดี มีคนที่ใช้ ZFS แล้วเสียใจไม่มากนัก ดังนั้นน่าจะถูกใจ
    • ZFS ถูกใช้ใน สภาพแวดล้อมจริง มาเกือบ 20 ปี แล้ว
      ตามเอกสารของ BTRFS นั้น BTRFS ยังไม่เหมาะกับสภาพแวดล้อมจริงอย่างสมบูรณ์: https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid5...
      ใน use case แบบเรียบง่ายบางส่วน อาจถือว่า BTRFS เพียงพอสำหรับสภาพแวดล้อมจริงได้ แต่ผลลัพธ์จะแตกต่างกันไปตามแต่ละสภาพแวดล้อม
    • btrfs มีเป้าหมายคล้ายกับ ZFS แต่ยังสุกงอมน้อยกว่ามาก
      เคยใช้กับพาร์ทิชัน root เพราะไม่ต้องใช้ DKMS แต่มีปัญหาเยอะ
      ใช้งานแบบค่อนข้างเรียบง่าย แค่มิเรอร์เท่านั้น แต่วันหนึ่งเมื่อไดรฟ์ตัวหนึ่งใน array มีปัญหา btrfs ก็รับมือได้ไม่ดี
      เท่าที่จำได้ มัน remount ทุกอย่างเป็น read-only และโดยค่าเริ่มต้นก็ไม่ทำงานในโหมด degraded
      แม้แต่ mdraid ที่ไม่มีฟีเจอร์อย่าง checksum ก็น่าจะดีกว่านี้
      ZFS ก็จะทำเครื่องหมายว่า array มีข้อบกพร่องเช่นกัน แต่แน่นอนว่ายังให้ใช้งานต่อได้
      ผมหมดความเชื่อถือเพราะพฤติกรรมเริ่มต้นไม่ใช่ RAID กล่าวคือส่วน R ที่หมายถึงการอ่านข้อมูลกลับมาแทบจะหายไปเลย
      หลังจากย้ายไป ZFS ก็ไม่มีปัญหา และยังมีคอมมูนิตี้กับเครื่องมือดี ๆ มากกว่ามาก
    • ใช้ Btrfs อยู่หลายปี แล้วเลิกใช้ไปเมื่อไม่กี่ปีก่อน
      ใน Btrfs ก็เคยมีเรื่องแปลก ๆ อยู่ครั้งสองครั้ง แต่สุดท้ายกู้คืนได้ทั้งหมด
      โดยรวมแล้วความยืดหยุ่นของ Btrfs นั้นดี แต่ในกรณีส่วนใหญ่รู้สึกว่ามันช้าเกินไป
      ตอนนี้ใช้ ZFS บน Arch Linux และจนถึงตอนนี้โดยรวมไม่มีปัญหา
      ยังมีการตั้งค่าและวิธีปรับแต่งเพื่อเพิ่มประสิทธิภาพได้มากกว่า
      ถ้าจะให้คำแนะนำสักอย่าง คือควร ศึกษาข้อมูลและทดสอบ ZFS ให้พอ มีช่วงเรียนรู้เล็กน้อย แต่สำหรับผมแล้วคุ้มค่าที่จะเปลี่ยน

  • ดีใจที่มี การเลี่ยง ARC เพื่อประสิทธิภาพของ NVMe
    ZFS มักใช้ศักยภาพของ NVMe ได้ไม่เต็มที่
    การขยายแบบออนไลน์ก็น่าสนใจเช่นกัน
    เคยลองใช้ ZFS กับฐานข้อมูลที่ยุ่งมาก ๆ แล้วโดน bug เรื่อง fragmentation เข้าอย่างจัง
    วิธีเดียวที่จะทำให้ประสิทธิภาพกลับมาดูเหมือนจะเป็นการคัดลอกข้อมูลออกจาก volume แล้วลบ volume ทิ้ง จากนั้นคัดลอกกลับเข้าไปใหม่
    ตอนนี้บางทีอาจขยาย zpool แล้วคัดลอก tablespace ภายใน volume เดียวกันเพื่อลด fragmentation ได้ก็เป็นได้

  • อีกประเด็นที่น่าดูคือ TrueNAS รองรับฟีเจอร์นี้แล้ว[0]
    ดูเหมือนน่าจะใช้ 2.3.0rc3 อยู่ แต่ยังไม่แน่ใจเรื่องเสถียรภาพ ถึงอย่างนั้นก็น่าตื่นเต้นมาก
    https://www.truenas.com/blog/electric-eel-openzfs-23/

  • ช่วยอธิบายได้ไหมว่าทำไมถึงใช้ของอย่าง ZFS ในบ้าน?

    • เหตุผลที่มันดีสำหรับผมคือแบบนี้
      เช็กซัม: สำหรับใช้งานในบ้านมักมีคุณภาพฮาร์ดแวร์ต่ำกว่า จึงยิ่งสำคัญเสียอีก มีหลายเหตุผลที่ทำให้ข้อมูลผิดพลาดถูกบันทึกลงไปได้ เช่น คอนโทรลเลอร์ที่มีข้อบกพร่อง สายเคเบิลคุณภาพแย่ ฮาร์ดดิสก์ที่ถูกเก็บไว้ในอุณหภูมิสูงกว่าที่แนะนำ และถ้ามีความซ้ำซ้อน ZFS ก็จะจัดการเรื่องนี้ให้โดยอัตโนมัติได้ดี
      สแนปช็อต: มีประโยชน์มากสำหรับการทำแบ็กอัป และย้อนกลับไปยังไฟล์เวอร์ชันเก่าได้อย่างรวดเร็วเมื่อทำพลาด
      ความสบายใจ: เมื่อเทียบกับทางเลือกอื่น ๆ ผมรู้สึกว่า ZFS ใช้ง่าย และทำพลาดจนทำให้ข้อมูลหายได้ยาก ตัวอย่างเช่น ระหว่างเปลี่ยนไดรฟ์ที่เสีย ถ้าเผลอถอดไดรฟ์ผิดจนพูลใช้งานไม่ได้ พอเสียบกลับเข้าไปมันก็กลับมาเหมือนไม่มีอะไรเกิดขึ้น
      ตอนนี้ mdadm อาจต่างไปแล้วก็ได้ แต่ตอนที่ผมใช้เมื่อหลายปีก่อน ผมกังวลตลอดว่าจะทำพลาดแบบทำลายข้อมูล
    • ถ้าจะตอบในมุมที่คนอื่นยังไม่ได้พูด ZFS เหมาะกับ การเก็บเกม Steam
      ถ้าตั้งค่า recordsize=1M และ compression=zstd บ่อยครั้งจะเก็บเกมได้เพิ่มขึ้นราว 33% ในพื้นที่เท่าเดิม
      เพื่อนคนหนึ่งใช้ ZFS เพื่อเก็บเกม Steam ไว้บนฮาร์ดดิสก์หลายลูก และให้ SSD เป็น L2ARC กับ ZFS
      ZFS จะ แคช เกมที่เล่นบ่อยลง SSD โดยอัตโนมัติ ทำให้โหลดได้เร็ว
      พอเกมที่ชอบเปลี่ยนไป ZFS ก็จะปรับตัวอัตโนมัติและแคชเกมเหล่านั้นลง SSD
    • ผมใช้ zrepl ทำสำเนาทั้งไฟล์ซิสเต็มไปยัง NAS ภายในทุก 10 นาที
      ตอน WD_BLACK SN850 ตายกะทันหัน [1] มันเคยช่วยไว้ได้มากแล้วครั้งหนึ่ง
      และยังช่วยกู้โค้ดที่หายไปจากความผิดพลาดแบบคลาสสิกของ git ได้ด้วย
      การเสียข้อมูลจากความผิดพลาดของผู้ใช้หรืออุปกรณ์เดี่ยวเสีย ไม่ควรเป็นเรื่องที่เกิดขึ้นได้อีกแล้ว เรามีเทคโนโลยีนั้นอยู่
      [1]: https://chromakode.com/post/zfs-recovery-with-zrepl/
    • มีหลายเหตุผล แต่เหตุผลใหญ่สำหรับผมคือ ความน่าเชื่อถือ และความพกพาข้ามระบบ
      ไม่มีไฟล์ซิสเต็มสมัยใหม่ตัวอื่นที่มีเช็กซัมและการซ่อมแซมตัวเอง และอ่านเขียนได้บน Linux, FreeBSD, Windows, macOS
      สแนปช็อต หรือก็คือ boot environment นั้น Btrfs ก็รองรับ การติดตั้ง Linux ของผมใช้มัน เพราะไม่อยากต้องกังวลกับเคอร์เนลโมดูลของบุคคลที่สามเพื่ออ่านรูทไฟล์ซิสเต็ม
      ประสิทธิภาพก็ไม่ได้ดีมากนัก และถ้าดูบน Linux แล้วประสิทธิภาพเป็นประเด็นหลัก XFS เป็นตัวเลือกที่ดีกว่า
    • ค่อนข้างง่ายแต่ทรงพลัง
      ก่อนหน้านั้นผมใช้ MDADM + LVM + dm-crypt + ext4 ซึ่งก็ทำงานได้ แต่มีหลายชั้นเกินไปจนปวดหัว
      สแนปช็อตอัตโนมัตินั้นง่ายและเร็วมาก
      เวลาลบไฟล์ไปก็เข้าถึงได้ง่าย ไม่ต้องกู้คืนสแนปช็อตทั้งชุด แค่ cp จากโฟลเดอร์ .zfs/ ที่ซ่อนอยู่ก็พอ
      ผมใช้งานด้วยดิสก์ 8TB จำนวน 6 ลูกมาหลายปีแล้ว เป็น RAIDZ2 จึงเสียได้มากสุด 2 ลูก
      ถ้าถามว่าจะใช้กับดิสก์ลูกเดียวบนเดสก์ท็อปไหม ก็คงไม่ทำ