Vấn đề mà nhiều sysadmin gặp phải khi chọn filesystem
Hồi mới bắt đầu làm sysadmin, mình từng mất cả buổi chiều debug vấn đề này chỉ vì không đọc kỹ log — một database server chạy MySQL bị giảm hiệu suất nghiêm trọng sau khi migrate sang server mới. Cuối cùng phát hiện ra nguyên nhân đơn giản: server mới dùng ext4 với mount options mặc định, trong khi server cũ dùng XFS được tuned kỹ cho workload random I/O cao.
Filesystem mặc định khi cài distro thường là ext4. Hầu hết không ai đặt câu hỏi — dù server đó chạy database, file server hay streaming. Nhưng câu hỏi “ext4 hay XFS?” nhìn có vẻ đơn giản, câu trả lời lại phụ thuộc hoàn toàn vào workload thực tế bạn đang chạy.
Tại sao filesystem ảnh hưởng nhiều hơn bạn nghĩ?
Filesystem không chỉ là nơi lưu file. Nó quyết định cách kernel quản lý metadata, cách xử lý journal, cơ chế phân bổ block và chiến lược cache. Với database server xử lý hàng nghìn transaction/giây, chênh lệch giữa các filesystem có thể lên đến 20–40% hiệu suất thực đo.
Trước khi chọn, có 4 yếu tố cần xem xét:
- Workload pattern: Sequential read/write (streaming, backup) hay random I/O (database, VM disk)?
- Kích thước file: Nhiều file nhỏ (mail server, web server) hay ít file lớn (video storage, backup)?
- Yêu cầu tính năng: Cần snapshot, compression hay RAID tích hợp không?
- Loại storage: HDD truyền thống, SSD, hay flash storage?
Phân tích từng hệ thống file
ext4 — Người quen đáng tin cậy
Cài Ubuntu lên server nào? ext4. CentOS? ext4. Debian? Cũng ext4 luôn. Không phải ngẫu nhiên — filesystem này ổn định, được kiểm tra kỹ qua hơn 15 năm và có bộ tool hỗ trợ phong phú nhất trong hệ sinh thái Linux.
Điểm mạnh:
- Journaling tốt, phục hồi sau crash nhanh và đáng tin
- Bộ tool chín muồi:
fsck,debugfs,tune2fs— documentation đầy đủ, StackOverflow đầy câu trả lời - Hoạt động ổn định với cả HDD và SSD
- Overhead thấp, phù hợp server có RAM giới hạn (dưới 4GB vẫn chạy tốt)
Hạn chế:
- Không có snapshot native — muốn snapshot phải dùng LVM hoặc tầng storage riêng
- Hiệu suất giảm khi thư mục chứa hàng trăm nghìn file nhỏ
- Không có compression hay deduplication tích hợp
Format và mount ext4 với options tối ưu cho SSD:
# Format với lazy initialization tắt (nhanh hơn cho SSD)
mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/sdb1
# Mount với options tối ưu — noatime giảm write, discard bật TRIM
mount -o noatime,discard /dev/sdb1 /data
# Thêm vào /etc/fstab
/dev/sdb1 /data ext4 defaults,noatime,discard 0 2
# Tune journal commit interval (mặc định 5s, tăng lên giảm I/O)
tune2fs -o journal_data_writeback /dev/sdb1XFS — Lựa chọn của database và workload nặng
XFS được Red Hat chọn làm default filesystem từ RHEL 7 — không phải ngẫu nhiên. Thiết kế từ đầu cho hiệu suất cao với large file và parallel I/O từ nhiều process đồng thời, đây là lý do XFS áp đảo trong benchmark database thực tế.
Điểm mạnh thực sự nổi bật:
- Hiệu suất tuyệt vời với large file và sequential I/O
- Metadata journaling riêng biệt, không ảnh hưởng data throughput
- Online resize — tăng kích thước khi đang mount, không cần downtime
- Delay allocation giúp giảm fragmentation đáng kể
- Concurrent write từ nhiều process tốt hơn ext4 rõ rệt, đặc biệt với 8+ threads đồng thời
Hạn chế:
- Không thể shrink filesystem — chỉ tăng được, không giảm. Tính toán kỹ dung lượng trước khi format
- Không có compression hay deduplication native
# Format XFS với sector size phù hợp enterprise SSD
mkfs.xfs -f -s size=4096 /dev/sdb1
# Mount với options cho database server
mount -o noatime,logbsize=256k,largeio /dev/sdb1 /data
# Kiểm tra và repair XFS (unmount trước)
xfs_repair /dev/sdb1
# Tăng kích thước XFS online (filesystem đang được mount)
xfs_growfs /data
# Xem thông tin chi tiết filesystem
xfs_info /dataBtrfs — Đầy tính năng, nhưng không phải cho mọi người
Fedora 33 chuyển sang Btrfs làm default — một quyết định khá táo bạo vào thời điểm đó. openSUSE dùng Btrfs từ sớm hơn nữa. Cả hai đều cược vào khả năng snapshot và self-healing của nó. Và nhìn lại, không sai.
Tính năng thực sự khác biệt:
- Snapshot native: Tạo snapshot instant, không tốn thêm space ngay lập tức nhờ copy-on-write
- Compression inline: LZO/zlib/zstd transparent — thực tế tiết kiệm 20–40% dung lượng với text/log
- Subvolumes: Quản lý linh hoạt hơn partition truyền thống, không cần chia sẵn dung lượng
- Checksum data + metadata: Phát hiện bit rot tự động — thứ mà ext4 hay XFS đều không làm được
Điểm cần cẩn thận trước khi dùng production:
- RAID 5/6 của Btrfs vẫn có bug đã biết — không dùng trong production, dùng mdadm hoặc ZFS thay thế
- Hiệu suất random write thuần túy kém hơn ext4/XFS khoảng 10–15% trong benchmark
btrfsckít mature hơne2fsck, recovery phức tạp hơn khi gặp corruption nghiêm trọng
# Format Btrfs
mkfs.btrfs -L "data-volume" /dev/sdb1
# Mount với zstd compression (ratio tốt, speed nhanh hơn zlib)
mount -o compress=zstd:3,noatime /dev/sdb1 /data
# Tạo subvolume (như partition logic, nhưng linh hoạt hơn)
btrfs subvolume create /data/www
btrfs subvolume create /data/db
# Snapshot read-only (instant, không tốn thêm space ban đầu)
btrfs subvolume snapshot -r /data/www /data/snapshots/www-$(date +%Y%m%d)
# Liệt kê tất cả subvolume và snapshot
btrfs subvolume list /data
# Kiểm tra usage với compression ratio
btrfs filesystem df /data
btrfs filesystem usage /dataF2FS — Chuyên biệt cho flash storage
Nếu bạn chưa từng gặp F2FS trên server enterprise, đó là bình thường. Samsung phát triển filesystem này để giải quyết vấn đề cụ thể: NAND flash có write amplification cao và wear pattern không đồng đều. F2FS tối ưu write pattern để kéo dài tuổi thọ thiết bị.
Điểm mạnh:
- Giảm write amplification trên NAND flash, kéo dài tuổi thọ SSD/eMMC đáng kể
- Hiệu suất random I/O tốt hơn ext4 trên SSD consumer-grade (thường 10–20% trong benchmark)
- Hot/cold data separation tự động, giảm fragmentation theo thời gian
Giới hạn:
- Chỉ phù hợp với flash storage — trên HDD sẽ hiệu suất kém hơn ext4
- Tool hỗ trợ và documentation ít hơn hẳn so với ext4/XFS
- Không phổ biến trong môi trường server enterprise
# Cài tool F2FS (Ubuntu/Debian)
apt install f2fs-tools
# Format F2FS
mkfs.f2fs /dev/sdb1
# Mount
mount -t f2fs /dev/sdb1 /data
# Kiểm tra thông tin
dump.f2fs /dev/sdb1Mapping thực tế: filesystem nào cho kịch bản nào
Từ kinh nghiệm vận hành thực tế, đây là cách mình mapping theo workload:
| Kịch bản | Filesystem khuyên dùng | Lý do chính |
|---|---|---|
| General purpose Linux server | ext4 | Ổn định, ít rủi ro, tool support tốt nhất |
| Database server (MySQL/PostgreSQL) | XFS | Concurrent I/O cao, metadata journal riêng |
| NAS / Storage server cần snapshot | Btrfs | Snapshot + compression tiết kiệm space đáng kể |
| Desktop Linux (Fedora/openSUSE) | Btrfs | Snapshot trước khi update, rollback dễ dàng |
| SSD consumer / thiết bị flash | F2FS | Tối ưu flash lifespan, random I/O tốt hơn |
| High-throughput log / streaming server | XFS | Sequential write nhanh, delay allocation tốt |
Kết hợp filesystem theo workload — thay vì ép 1 cái cho tất cả
Production server ít khi chỉ có 1 workload đồng nhất. Server database + backup thì cần 2 filesystem khác nhau — không cần ép vào 1 cái cho tiện. Mình thường chia như sau:
# Xem layout hiện tại
lsblk -f
# Ví dụ layout tối ưu cho database + backup server:
# /dev/sda1 ext4 / — Root: ổn định, recovery dễ
# /dev/sdb1 xfs /var/lib/mysql — Database: concurrent I/O cao
# /dev/sdc1 btrfs /backup — Backup: compression + snapshot
# Kiểm tra mount options tất cả filesystem đang dùng
findmnt -t ext4,xfs,btrfs -o TARGET,SOURCE,OPTIONS
# Benchmark nhanh để so sánh trước khi quyết định
# (cài fio: apt install fio)
fio --name=randwrite --ioengine=libaio --rw=randwrite \
--bs=4k --numjobs=4 --size=1G --runtime=30 \
--filename=/data/testfile --direct=1Bài học đắt giá nhất mình từng học: đừng migrate filesystem khi server đang production mà chưa test kỹ. Lần mình chuyển MySQL data partition từ ext4 sang XFS, mất gần 4 tiếng downtime vì quên dump và verify toàn bộ data trước. Test trên staging, benchmark với workload thực tế của bạn — rồi mới đụng production.
Rule of thumb cá nhân: ext4 cho / (root), XFS cho data disk chạy database hoặc log nặng, Btrfs cho storage server cần snapshot và compression. F2FS chỉ xuất hiện trong radar khi làm việc với flash storage thuần — laptop cũ, Raspberry Pi, thiết bị nhúng.
