Điểm giới hạn của các Filesystem truyền thống
EXT4 đã phục vụ tôi trung thành trong gần một thập kỷ. Nó giống như chiếc Toyota Corolla của giới filesystem—đáng tin cậy, dễ đoán và gần như không thể phá hủy.
But khi hạ tầng của tôi mở rộng lên 15 node production, những rắc rối bắt đầu xuất hiện. Tôi đã phải thức trắng đêm bảo trì lúc 3 giờ sáng, unmount các phân vùng quan trọng chỉ để cố nhồi thêm 20GB dung lượng vào một volume đã đầy 98%. Việc backup cơ sở dữ liệu 2.4TB mất gần 6 tiếng, and một thay đổi cấu hình sai thường đồng nghĩa với một quá trình restore đầy đau đớn từ các công cụ image bên ngoài.
Sáu tháng trước, tôi đã chuyển stack chính của mình sang Btrfs. Tôi cần một hệ thống cung cấp khả năng khôi phục tức thì, các storage pool linh hoạt và tính toàn vẹn dữ liệu gốc. Sau nhiều năm quản lý hàng chục instance VPS, tôi không chuyển đổi một cách mù quáng. Tôi đã dành ba tuần để benchmark các mô hình I/O and giả lập mất điện trước khi tin tưởng giao dữ liệu thực tế cho nó. Đây là thực tế vận hành Btrfs trong môi trường production suốt nửa năm qua.
Các khái niệm cốt lõi: Sức mạnh của Copy-on-Write
Btrfs (B-Tree Filesystem) hoạt động khác với các filesystem mà hầu hết chúng ta từng sử dụng. Nó tận dụng cơ chế Copy-on-Write (CoW). Trong khi EXT4 ghi đè dữ liệu tại chỗ—xóa phiên bản cũ một cách hiệu quả—thì Btrfs ghi dữ liệu đã sửa đổi vào một block hoàn toàn mới trước. Chỉ sau khi việc ghi thành công, nó mới cập nhật metadata để trỏ đến vị trí mới. Lựa chọn thiết kế duy nhất này cho phép triển khai hầu hết mọi tính năng nâng cao mà filesystem này cung cấp.
Subvolumes so với Phân vùng cố định
Quản lý không gian lưu trữ từng là một bài toán khó. Nếu tôi cấp 100GB cho /var and nó bị đầy, tôi không thể chạm vào 500GB đang nhàn rỗi trong /home mà không thực hiện một “vũ điệu” phân chia lại phân vùng đầy rủi ro. Btrfs loại bỏ các ranh giới này bằng cách sử dụng subvolume. Hãy coi subvolume như những thư mục “quyền năng” hoạt động giống như các filesystem độc lập. Chúng chia sẻ một pool không gian trống duy nhất. Nếu database của bạn cần thêm 10GB hôm nay, nó chỉ việc lấy từ pool chung đó. Không cần unmount.
Snapshots: Tấm lưới an toàn tức thì
Snapshot giúp loại bỏ nỗi lo “thôi xong rồi” trong quản trị hệ thống. Nhờ kiến trúc CoW, việc tạo một snapshot gần như diễn ra tức thì. Nó không thực sự sao chép bất kỳ dữ liệu nào; nó chỉ đơn giản ghi lại trạng thái hiện tại của metadata. Một snapshot của subvolume 1TB chỉ mất khoảng 0.2 giây để tạo and không tốn thêm dung lượng cho đến khi bạn bắt đầu sửa đổi các file. Giờ đây tôi luôn tạo một snapshot trước mỗi lần apt upgrade hoặc thay đổi cấu hình Nginx.
Thực hành: Triển khai Btrfs
Việc thiết lập yêu cầu gói btrfs-progs. Trên Ubuntu hoặc Debian, chạy apt install btrfs-progs. Trên Fedora, sử dụng dnf install btrfs-progs.
1. Tạo Filesystem
Nếu bạn có một ổ đĩa mới tại /dev/sdb, việc định dạng rất đơn giản. Sử dụng nhãn (label) để tệp /etc/fstab của bạn dễ đọc hơn:
sudo mkfs.btrfs -L production_storage /dev/sdb2. Tổ chức với Subvolume
Tôi thích tạo các subvolume riêng biệt cho các loại dữ liệu khác nhau. Điều này cho phép snapshot chi tiết and các tùy chọn mount khác nhau cho mỗi loại.
# Mount ổ đĩa gốc chính
sudo mount /dev/sdb /mnt/btrfs_root
# Tạo các subvolume cho web root và backup database
sudo btrfs subvolume create /mnt/btrfs_root/www
sudo btrfs subvolume create /mnt/btrfs_root/db_backups
# Kiểm tra kết quả
sudo btrfs subvolume list /mnt/btrfs_root3. Nén dữ liệu trong suốt (Kéo dài tuổi thọ SSD)
Nén dữ liệu trong suốt (Transparent compression) là một thắng lợi lớn cho máy chủ log của tôi. Btrfs xử lý việc nén ở cấp độ kernel, vì vậy các ứng dụng của bạn thậm chí không biết điều đó đang xảy ra. Tôi sử dụng zstd vì nó đạt được sự cân bằng hoàn hảo giữa việc tiết kiệm không gian and giữ mức sử dụng CPU thấp. Trong môi trường của tôi, thư mục /var/log đã giảm từ 45GB xuống chỉ còn 18GB—giảm 60%.
Thêm dòng này vào /etc/fstab để kích hoạt:
LABEL=production_storage /data btrfs defaults,compress=zstd:3,autodefrag 0 0Điều này không chỉ tiết kiệm không gian; nó còn kéo dài tuổi thọ của SSD bằng cách giảm tổng số lần ghi vật lý vào các cell NAND.
4. Khôi phục sự cố trong vài giây
Trước khi chạm vào bất kỳ dòng code nào trong một web app production, tôi sẽ chạy một snapshot chỉ đọc (read-only). Nếu mọi thứ hỏng hóc, tôi không mất công tìm lỗi; tôi chỉ việc rollback.
# Tạo một snapshot chỉ đọc có gắn mốc thời gian
sudo btrfs subvolume snapshot -r /mnt/btrfs_root/www /mnt/btrfs_root/www_pre_update_$(date +%F)
# Để khôi phục, tráo đổi subvolume bị hỏng bằng snapshot
sudo mv /mnt/btrfs_root/www /mnt/btrfs_root/www_broken
sudo btrfs subvolume snapshot /mnt/btrfs_root/www_pre_update_2024-05-20 /mnt/btrfs_root/wwwDuy trì sức khỏe hệ thống
Btrfs không phải là công cụ “thiết lập rồi quên luôn” như EXT4. Nó yêu cầu bảo trì định kỳ để tránh suy giảm hiệu suất. Tôi đã tự động hóa hai tác vụ trong lịch bảo trì hàng tháng của mình.
Scrubbing: Chống lại hiện tượng Bit Rot
Btrfs lưu trữ checksum cho mỗi bit dữ liệu. Một lượt “scrub” sẽ đọc mọi block and xác minh nó so với checksum. Tháng trước, một lượt scrub đã phát hiện 4 lỗi checksum trên một ổ SSD 2TB cũ. Vì tôi đang chạy thiết lập Btrfs RAID, filesystem đã tự động sửa các lỗi đó bằng cách sử dụng bản mirror khỏe mạnh.
sudo btrfs scrub start /data
sudo btrfs scrub status /dataBalancing (Cân bằng)
Sau nhiều lần xóa hoặc xoay vòng snapshot, các chunk nội bộ của filesystem có thể bị phân bổ không hiệu quả. Balancing sẽ phân phối lại dữ liệu để thu hồi không gian. Tôi thường nhắm mục tiêu vào các chunk được sử dụng ít hơn 50% để quá trình diễn ra nhanh chóng.
sudo btrfs balance start -dusage=50 /dataKết luận sau 6 tháng
Chuyển sang Btrfs là bước đi hạ tầng tốt nhất mà tôi đã thực hiện trong năm nay. Khả năng thực hiện rollback tức thì đã cứu tôi ít nhất ba lần trong các đợt triển khai lỗi. Mặc dù bạn cần theo dõi metadata and chạy scrub thường xuyên, nhưng sự linh hoạt của subvolume khiến việc phân vùng truyền thống cảm giác như đang dùng điện thoại “cục gạch” trong thời đại smartphone.
Nếu bạn đã mệt mỏi với các giới hạn đĩa cố định and thời gian backup chậm chạp, hãy bắt đầu từ quy mô nhỏ. Gắn một ổ đĩa dữ liệu phụ với Btrfs and thử nghiệm với snapshot. Một khi bạn thấy quá trình restore 50GB diễn ra trong chưa đầy một giây, bạn sẽ không bao giờ muốn quay lại.
