ZFS 2.3 ra mắt, bao gồm tính năng mở rộng RAIDZ

 (github.com/openzfs)
1 điểm bởi GN⁺ 2025-01-15 | 1 bình luận | Chia sẻ qua WhatsApp
  • OpenZFS 2.3.0 đưa RAIDZ Expansion trở thành tính năng trọng tâm, cho phép thêm thiết bị mới vào pool RAIDZ hiện có để tăng dung lượng mà không cần downtime
  • Fast Dedup cải thiện đáng kể hiệu năng của tính năng khử trùng lặp hiện có, đồng thời đi kèm các cải thiện hiệu năng trên toàn bộ codebase
  • Direct IO cho phép bỏ qua ARC khi đọc/ghi, nhắm đến các môi trường nơi caching có thể làm giảm hiệu quả, chẳng hạn thiết bị NVMe
  • Bổ sung đầu ra JSON tùy chọn cho các lệnh thường dùng, hỗ trợ tên tệp và thư mục tối đa 1023 ký tự, cùng các bản sửa lỗi quan trọng xử lý vấn đề ở phiên bản trước
  • Phạm vi hỗ trợ gồm Linux kernel 4.18~6.12 và FreeBSD 13.3, 14.0~14.2; chu kỳ phát hành lần này có 134 người tham gia đóng góp

Những thay đổi trong OpenZFS 2.3.0

  • OpenZFS 2.3.0 được cập nhật xoay quanh mở rộng lưu trữ, hiệu năng khử trùng lặp, đường dẫn I/O, định dạng đầu ra lệnh và hỗ trợ độ dài tên tệp
  • Thẻ phát hành là zfs-2.3.0, bao gồm các thay đổi kể từ OpenZFS 2.2.0

Mở rộng lưu trữ và cải thiện hiệu năng

  • RAIDZ Expansion cho phép thêm thiết bị mới vào pool RAIDZ hiện có để tăng dung lượng lưu trữ mà không cần downtime
  • Fast Dedup là nâng cấp lớn về hiệu năng cho tính năng khử trùng lặp hiện có của OpenZFS
  • Direct IO cho phép bỏ qua ARC trong thao tác đọc/ghi
    • Nhắm đến cải thiện hiệu năng trong những tình huống caching có thể cản trở hiệu quả, như với thiết bị NVMe
  • Cũng bao gồm nhiều cải thiện hiệu năng trên toàn bộ codebase

Đầu ra lệnh và độ dài tên

  • JSON bổ sung đầu ra JSON tùy chọn cho các lệnh được dùng nhiều nhất
  • Long names hỗ trợ tên tệp và thư mục dài tối đa 1023 ký tự

Độ ổn định, nền tảng và đóng góp

  • Bao gồm các bản sửa lỗi quan trọng xử lý những vấn đề được báo cáo ở các phiên bản trước
  • Nền tảng được hỗ trợ:
    • Linux kernel 4.18~6.12
    • FreeBSD 13.3, 14.0~14.2
  • Chu kỳ phát hành lần này có 134 người đóng góp tham gia

Tài liệu và nhật ký thay đổi

Thay đổi tùy chọn mô-đun

  • Danh sách đầy đủ các tùy chọn và đối tượng điều khiển được tổng hợp trong tài liệu module parameters
  • Các tùy chọn mô-đun mới bao gồm các mục liên quan đến mở rộng RAIDZ, log khử trùng lặp, Direct IO, allocator, scrub và resilver
    • Ví dụ: raidz_expand_max_copy_bytes, raidz_expand_max_reflow_bytes, zfs_dio_enabled, zfs_dedup_log_mem_max, zfs_scrub_after_expand
  • Tùy chọn mô-đun đã bị loại bỏ:
    • zfetch_array_rd_sz
  • Tùy chọn mô-đun đã thay đổi:
    • zfs_arc_shrinker_limit
    • zfs_bclone_enabled
    • zfs_vdev_disk_classic
    • zio_taskq_write

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-01-15
Các ý kiến trên Hacker News

  • Mở rộng ZFS RAIDZ, vốn đã được chuẩn bị trong nhiều năm, cuối cùng cũng được đưa vào
    Các tính năng chính gồm mở rộng RAIDZ, cho phép thêm thiết bị vào pool RAIDZ hiện có để tăng dung lượng mà không gián đoạn; khử trùng lặp nhanh, cải thiện đáng kể hiệu năng khử trùng lặp của OpenZFS; I/O trực tiếp, bỏ qua ARC để cải thiện hiệu năng trong các môi trường nơi cache có thể kém hiệu quả như NVMe; xuất JSON tùy chọn cho các lệnh thường dùng; và hỗ trợ tên tệp/thư mục dài tối đa 1023 ký tự

    • Chính xác hơn, điều đó có nghĩa là có thể gắn thiết bị mới, tức là đĩa, vào RAIDZ vdev hiện có
    • Nếu đang chạy Proxmox trên ZFS và NVMe, tôi tò mò liệu có nên bật I/O trực tiếp khi 2.3 được phân phối hay không
      Tôi muốn biết tính năng này phù hợp với trường hợp sử dụng nào
    • Bốn tính năng đầu thực sự có vẻ là những thay đổi lớn
    • Tuy vậy, có lẽ vẫn nên xem như xóa vdev là chưa thể làm được
    • Tôi tò mò tính năng này đã được kiểm thử tốt đến mức nào khi dùng cùng mã hóa
      Tôi cũng nghi ngờ liệu đội ZFS có thực sự coi mã hóa là ưu tiên hạng nhất hay không
      ZFS trên Linux thừa hưởng nhiều danh tiếng của ZFS trên Solaris, nhưng những ai dùng trong môi trường vận hành cần xem khá kỹ issue tracker để thấy thực tế

  • Tôi không hiểu vì sao phía Windows, nền tảng PC áp đảo về số người dùng, đến giờ vẫn chưa có câu trả lời cho ZFS
    Microsoft từng có WinFS, rồi sau đó là ReFS, nhưng chúng đã bị đẩy xuống hàng sau; việc phát triển vẫn tiếp diễn và thỉnh thoảng một số phần xuất hiện trong Win11, nhưng chưa thấy bản phát hành chính thức
    Một vài cá nhân đang thử thực hiện công việc lớn là tạo lớp tương thích ZFS, nhưng vẫn còn rất xa mức trưởng thành hoặc có thể dùng thực tế
    Tôi không hiểu vì sao Windows đến giờ vẫn dùng một hệ thống tệp đã 32 năm tuổi

    • Thành thật mà nói, tình hình Linux cũng không khá hơn nhiều
      ZFS có vấn đề giấy phép với Linux nên bị cản trở việc tích hợp hoàn toàn, còn Btrfs đã phát triển 15 năm nhưng vẫn chưa bằng ZFS về tính năng và độ ổn định
      Hầu hết các bản phân phối Linux vẫn dùng ext4 19 năm tuổi làm mặc định; thực ra ext4 cũng gần như chỉ là các phần mở rộng đặt lên ext2, vốn cùng tuổi với NTFS
      Công bằng mà nói, hiếm có thành phần hệ điều hành nào quan trọng như hệ thống tệp, và nhiều người không muốn động tới một hệ thống tệp chưa được kiểm chứng hơn 10 năm trong môi trường vận hành
    • Lý do đơn giản thôi. Phần lớn gánh nặng mà hệ thống tệp phải chịu đã được phần cứng lưu trữ doanh nghiệp nơi đặt hệ thống tệp đó đảm nhận
      Các tính năng cần thiết như snapshot, khử trùng lặp cấp block, công nghệ lưu trữ đối tượng, RAID/khả năng phục hồi, thay đổi kích thước, v.v. đều do thiết bị lưu trữ phụ trách
      Các appliance lưu trữ hiện đại gần như ở mức ma thuật đen, nên NTFS không nhất thiết cần thêm nhiều tính năng hơn
      Có thể truy cập trong suốt qua NAS/SAN, hoặc lưu volume NTFS trên một hộp đĩa đủ năng lực
      Ở các mảng cao cấp trong thế giới Linux có Lustre và GPFS, còn ZFS nhìn chung phù hợp với các mục đích không đặt hiệu năng làm trọng tâm nhưng cần khả năng phục hồi
    • Trong kernel Linux mainline cũng không có câu trả lời tương đương ZFS
      Tôi nghĩ là vì việc đó khó và rủi ro cao, trong khi phần thưởng phần lớn chỉ dừng ở sự kính trọng về mặt kỹ thuật
    • Từ góc nhìn người dùng cuối dùng Windows và Linux nhưng không dùng ZFS, tôi tò mò không biết mình đang bỏ lỡ điều gì
    • OpenZFS cho Windows đã đạt trạng thái release candidate (rc11), và còn một số lỗi quanh việc mount volume
      Không nghiêm trọng, nhưng hiện tại tốt nhất nên tránh mã hóa; tốc độ phát triển nhanh đến mức cứ vài tuần lại có release candidate mới để sửa các vấn đề còn lại
      Nếu kết hợp thêm Storage Spaces để pool các đĩa khác loại hoặc khác dung lượng, rồi định nghĩa vị trí, độ dư thừa và phân tầng theo từng Space, Windows giờ trở thành một nền tảng lưu trữ cao cấp
      Dùng Windows Server, chẳng hạn bản 2022/2025 Essentials giá rẻ, cũng có thể dùng SMB Direct/RDMA qua LAN và trên đĩa cứng ảo .vhdx với hiệu năng tối đa 10Gbyte/s, trở thành lựa chọn thay thế nhanh hơn iSCSI mà không cần cấu hình
      Vì vậy tôi đã port napp-it cs, GUI web cho ZFS, từ Solaris sang Windows để quản lý Storage Spaces, ZFS và cả các máy chủ OpenZFS từ xa như Proxmox; miễn phí cho mục đích phi thương mại

  • Tôi thích việc họ thiết kế tính năng mở rộng khá thận trọng
    Việc mở rộng không chỉ hoàn toàn minh bạch và có thể tiếp tục lại, mà còn duy trì tính dư thừa trong suốt quá trình
    Tuy nhiên có một lưu ý nhỏ mà mọi người nên biết
    Ngay cả sau khi mở rộng xong, các block cũ vẫn giữ tỷ lệ dữ liệu so với parity như trước. Ví dụ RAIDZ2 5-wide sẽ được phân tán trên một tập đĩa lớn hơn trong trạng thái 3 phần dữ liệu so với 2 phần parity
    Các block mới sẽ được ghi theo tỷ lệ dữ liệu so với parity mới. Ví dụ nếu mở rộng RAIDZ2 5-wide một lần thành 6-wide, nó sẽ trở thành 4 phần dữ liệu so với 2 phần parity

    • Tôi không chắc đó có thật sự là một lưu ý hay không. Nó chỉ có nghĩa là dữ liệu hiện có có thể vẫn nằm trong cách bố trí chưa tối ưu
      Dù vậy lợi ích của RAIDZ N vẫn giữ nguyên, nên pool vẫn tiếp tục hoạt động ngay cả khi tối đa N đĩa hỏng hoàn toàn
    • Lưu ý đó là hành vi hoàn toàn có thể dự đoán được. Thường nên hiểu rằng các tính năng ZFS không ghi lại các block hiện có
      Ví dụ, thay đổi cấu hình cũng chỉ áp dụng cho dữ liệu mới
    • Thành thật mà nói thì đó là một lưu ý khá lớn
      Da1 Db1 Dc1 Pa1 Pb1
      Da2 Db2 Dc2 Pa2 Pb2
      Da3 Db3 Dc3 Pa3 Pb3
      ___ ___ ___ Pa4 Pb4
      Ở đây ___ là dung lượng trống. Nếu thêm một đĩa để mở rộng, về mặt logic có thể kỳ vọng như sau
      Da1 Db1 Dc1 Da2 Pa1 Pb1
      Db2 Dc2 Da3 Db3 Pa2 Pb2
      Dc3 ___ ___ ___ Pa3 Pb3
      ___ ___ ___ ___ Pa4 Pb4
      Nhưng theo hiểu biết của tôi, thực tế nó được mở rộng như sau
      Da1 Db1 Dc1 Dd1 Pa1 Pb1
      Da2 Db2 Dc2 Dd2 Pa2 Pb2
      Da3 Db3 Dc3 Dd3 Pa3 Pb3
      ___ ___ ___ ___ Pa4 Pb4
      Trong đó các block Dd1~3 chỉ bị lãng phí. Tức là ngay cả khi thêm đĩa mới vào mảng, dung lượng trống chỉ tăng thêm 25%
      Ví dụ nếu ban đầu bạn có tổng dung lượng usable 24TB từ các đĩa 8TB và trước khi mở rộng còn trống 4TB, thì sau khi mở rộng dung lượng trống sẽ thành 5TB
      Tôi mong ai đó nói rằng tôi hiểu nhầm. Nếu không phải hiểu nhầm thì đây có vẻ là một triển khai khá vô dụng

  • Đây là tin lớn với người dùng ZFS. Có lẽ đặc biệt lớn với người dùng sở thích/gia đình, nhưng dù sao vẫn là chuyện lớn
    Mở rộng RAIDZ là một trong những tính năng được yêu cầu nhiều nhất trong nhiều năm

    • Tôi vẫn chưa quen với ZFS và cũng không tìm thấy trong release notes, nên tôi thắc mắc liệu việc mở rộng có chỉ hoạt động với các đĩa cùng kích thước hay không
      Tôi muốn biết có thể thêm đĩa lớn hơn hoặc nhỏ hơn không, hay tất cả đĩa phải có cùng kích thước

  • Đây là mở rộng online. Bản thân việc mở rộng trước đây cũng có thể làm được, nhưng phải hạ mảng xuống
    Chuyển sang ổ lớn hơn cũng có thể, nhưng phải thay từng ổ một, và dĩ nhiên chỉ sau khi nâng cấp tất cả ổ thì mới có được dung lượng mới
    Theo tôi biết thì việc thu nhỏ pool vẫn chưa thể làm được. Vì vậy nếu thêm ổ thứ 6 vào pool 5 ổ, thì dù dữ liệu rất ít cũng không thể quay lại còn 5 ổ

  • Cuối cùng cũng có!
    Giờ đây cũng có thể dùng một cấu hình vdev đơn kiểu RAID-Z3 hơi điên rồ, với 4 ổ cứng đắt nhất và mật độ cao nhất có thể mua hiện nay
    Ban đầu vì có mức dư thừa tương đương 3 đĩa nên tỷ lệ dung lượng hiệu dụng chỉ là 25%, nhưng mỗi khi nhu cầu dung lượng tăng, có thể mua thêm từng đĩa một và mở rộng lên khoảng 12 đĩa
    Theo thời gian giá đĩa sẽ giảm, và vì các đĩa được thêm vào ở những thời điểm khác nhau nên xác suất hỏng cũng được phân tán

    • Đúng, nhưng cũng nên xem bình luận cùng nhánh
      Dù mở rộng mảng, dữ liệu hiện có sẽ không được lưu trữ hiệu quả hơn
      Để có tỷ lệ parity/dữ liệu mới, bạn phải buộc sao chép dữ liệu và xóa phiên bản cũ kém hiệu quả. Chẳng hạn cần một công cụ như thế này [1]
      Cá nhân tôi cho rằng tốt hơn nhiều là mua các cấu hình RAID-Z hoàn chỉnh riêng lẻ rồi thêm cấu hình mới, hoặc thay thế cấu hình cũ theo từng đĩa
      [1] https://github.com/markusressel/zfs-inplace-rebalancing

  • Tò mò không biết ZFS so với btrfs thì thế nào
    Hiện mình đang dùng btrfs trên home server và đã gặp vài vấn đề kỳ lạ
    Đang nghĩ đến việc chuyển sang ZFS, nhưng không muốn rơi vào tình huống tương tự

    • Lần đầu mình dùng thử btrfs là khoảng 15 năm trước, vào thời Linux 2.6.33-rc4
      Chỉ sau 3 ngày đã xuất hiện một file không thể xóa được nên mình ngừng dùng, và về sau tìm đến ZFS
      ZFS cũng có vài vấn đề ít nghiêm trọng hơn, nhưng lúc đó mình là sinh viên khoa học máy tính, và so với những gì gặp ở btrfs thì chúng có vẻ nhỏ nhặt nên mình nghĩ có thể sửa được
      Trong 18 tháng tiếp theo, mình đã xử lý hết các vấn đề gây khó chịu và gửi patch lên kho ZFSOnLinux lúc bấy giờ; nỗ lực đó đã góp phần giúp ZFS có thể dùng trong môi trường vận hành trên Linux
      Từ đó đến nay mình tiếp tục dùng ZFS và nó hoạt động tốt
      Nếu tình trạng btrfs khi ấy tốt hơn, có lẽ mình đã trở thành người đóng góp cho btrfs. Nhưng không chỉ trạng thái lúc đó tệ, mà cả về sau, mỗi lần thử dùng cho mục đích nghiêm túc, nó vẫn liên tục bị những vấn đề kiểu còn dung lượng nhưng hay báo ENOSPC cản trở
      Ngược lại, ZFS đơn giản là hoạt động. Mình và nhiều người khác đã làm rất nhiều việc để nó hoạt động tốt
      Khác biệt lớn nhất là ZFS có nền tảng rất vững chắc, nhờ hệ thống kiểm thử hồi quy xuất sắc
      Phiên bản chạy ở user space thực thi mã một cách ngẫu nhiên để tìm lỗi trước khi chúng phát nổ trong môi trường vận hành, và mỗi thay đổi được đề xuất đều chạy một bộ kiểm thử để lọc lỗi
      ZFS cũng có nhiều người xem xét các thay đổi được đề xuất hơn so với các hệ thống file khác. Các lập trình viên Btrfs cũng thường nói rằng có chênh lệch lớn về nhân lực giữa hai hệ thống file, mình nhớ đại khái là khoảng 6 lần
      Dù sao thì rất hiếm người dùng ZFS rồi hối hận, nên có lẽ bạn sẽ thích nó
    • ZFS đã được dùng trong môi trường vận hành gần 20 năm
      Theo tài liệu BTRFS, BTRFS vẫn chưa hoàn toàn phù hợp cho môi trường vận hành: https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid5...
      Một số trường hợp sử dụng đơn giản có thể xem là đủ dùng trong vận hành với BTRFS, nhưng kết quả còn tùy môi trường
    • btrfs có mục tiêu tương tự ZFS nhưng kém trưởng thành hơn nhiều
      Vì không cần DKMS nên mình đã dùng nó cho phân vùng root, nhưng gặp nhiều vấn đề
      Mình dùng khá đơn giản, chỉ dạng mirror, vậy mà một ngày nọ khi một ổ trong array gặp vấn đề, btrfs đã không trụ được đúng cách
      Theo mình nhớ, nó remount mọi thứ thành read-only, và theo mặc định thì không chạy ở chế độ degraded
      Ngay cả mdraid không có các tính năng như checksum có lẽ còn tốt hơn thế
      ZFS cũng sẽ đánh dấu array là có lỗi, nhưng đương nhiên vẫn cho phép tiếp tục sử dụng
      Mình mất niềm tin vì hành vi mặc định không đúng nghĩa là RAID, tức phần R dùng để đọc lại dữ liệu trên thực tế gần như bị thiếu
      Từ khi chuyển sang ZFS thì không còn vấn đề, cộng đồng và công cụ tốt cũng nhiều hơn hẳn
    • Mình đã dùng Btrfs vài năm rồi rời bỏ nó vài năm trước
      Với Btrfs cũng từng có một hai chuyện kỳ lạ, nhưng cuối cùng đều khôi phục được
      Nhìn chung mình thích sự linh hoạt của Btrfs, nhưng trong hầu hết trường hợp cảm thấy nó quá chậm
      Hiện mình dùng ZFS trên Arch Linux và cho đến nay nhìn chung không có vấn đề
      Nó cũng có nhiều tùy chỉnh và cách hơn để tối ưu hiệu năng
      Nếu có một lời khuyên thì với ZFS, bạn nên tìm hiểu và thử nghiệm thật kỹ. Có một chút đường cong học tập, nhưng với mình thì việc chuyển đổi là xứng đáng

  • Việc có bỏ qua ARC để phục vụ hiệu năng NVMe là điều đáng mừng
    ZFS thường không tận dụng hết tiềm năng của NVMe
    Mở rộng online cũng có thể thú vị
    Mình từng thử dùng ZFS cho một cơ sở dữ liệu rất bận và bị dính nặng một lỗi phân mảnh
    Cách duy nhất để khôi phục hiệu năng dường như là sao chép dữ liệu ra khỏi volume, xóa volume rồi chép lại
    Giờ có lẽ có thể mở rộng zpool rồi sao chép tablespace trong cùng volume để giảm phân mảnh

  • Việc TrueNAS đã hỗ trợ tính năng này cũng đáng chú ý[0]
    Có vẻ họ đang dùng 2.3.0rc3, không rõ độ ổn định thế nào nhưng rất đáng mong đợi
    https://www.truenas.com/blog/electric-eel-openzfs-23/

  • Có thể giải thích vì sao dùng thứ như ZFS cho gia đình không?

    • Với tôi, lý do tốt là như sau
      Checksum: Với nhu cầu gia đình, chất lượng phần cứng thường thấp nên điều này lại càng quan trọng hơn. Có nhiều lý do khiến dữ liệu sai bị ghi lại, như bộ điều khiển lỗi, cáp kém, ổ cứng được đặt ở nhiệt độ cao hơn khuyến nghị, v.v.; nếu có tính dư thừa, ZFS sẽ tự động xử lý tốt các vấn đề này
      Snapshot: Rất hữu ích để tạo bản sao lưu và nhanh chóng quay về phiên bản cũ của tệp khi lỡ làm sai
      Yên tâm: So với các lựa chọn thay thế, tôi thấy ZFS dễ dùng và khó mắc sai lầm dẫn đến mất dữ liệu. Ví dụ, khi thay ổ bị hỏng mà lỡ rút nhầm ổ khiến pool không dùng được, chỉ cần cắm lại là nó hoạt động như chưa có gì xảy ra
      Bây giờ mdadm có thể đã khác, nhưng khi tôi dùng vài năm trước, tôi luôn bất an vì sợ mắc sai lầm mang tính phá hủy
    • Nếu trả lời theo hướng người khác chưa nói, thì ZFS tốt cho lưu game Steam
      Khi đặt recordsize=1M và compression=zstd, trong nhiều trường hợp có thể lưu được thêm khoảng 33% game trên cùng một dung lượng
      Một người bạn dùng ZFS để lưu game Steam trên vài ổ cứng. Và cấp SSD cho ZFS làm L2ARC
      ZFS tự động cache các game hay chạy lên SSD để tải nhanh hơn
      Khi game yêu thích thay đổi, ZFS tự thích nghi và cache những game đó lên SSD
    • Tôi dùng zrepl để sao chép toàn bộ hệ thống tệp sang NAS cục bộ mỗi 10 phút
      Nó đã từng giúp tôi rất nhiều khi WD_BLACK SN850 đột ngột chết [1]
      Nó cũng khôi phục được mã nguồn bị mất do một lỗi git kinh điển
      Việc mất dữ liệu do lỗi người dùng hoặc hỏng một thiết bị đơn lẻ đáng ra giờ không còn có thể xảy ra nữa. Chúng ta có công nghệ đó
      [1]: https://chromakode.com/post/zfs-recovery-with-zrepl/
    • Có nhiều lý do, nhưng với tôi lý do lớn là độ tin cậy và tính di động
      Không có hệ thống tệp hiện đại nào khác vừa có checksum và tự chữa lỗi, vừa có thể đọc/ghi trên Linux, FreeBSD, Windows, macOS
      Snapshot, tức môi trường khởi động, thì Btrfs cũng hỗ trợ. Bản cài Linux của tôi dùng nó để khỏi phải lo về module kernel bên thứ ba chỉ để đọc hệ thống tệp gốc
      Hiệu năng cũng không thật xuất sắc; nếu xét trên Linux mà hiệu năng là mối quan tâm chính thì XFS là lựa chọn tốt hơn
    • Tương đối dễ nhưng mạnh mẽ
      Trước đó tôi dùng MDADM + LVM + dm-crypt + ext4; nó cũng chạy được, nhưng quá nhiều lớp nên rất đau đầu
      Snapshot tự động rất dễ và nhanh
      Khi xóa tệp, việc truy cập lại cũng dễ, không cần khôi phục toàn bộ snapshot mà chỉ cần cp từ thư mục .zfs/ ẩn
      Tôi đã chạy nhiều năm với 6 ổ đĩa 8TB. Vì là RAIDZ2 nên có thể chịu được tối đa 2 ổ chết
      Nếu hỏi có dùng cho một ổ đơn trên desktop không thì có lẽ tôi sẽ không làm vậy