Btrfs — Konsep & Arsitektur#
Dokumentasi konsep Btrfs sebagai pembanding LVM/ZFS/Ceph — melengkapi seri dokumen storage. Relevan juga karena banyak NAS consumer (Asustor ADM, Synology) memakai Btrfs di balik layar.
1. Big Picture#
Btrfs mirip ZFS dalam filosofi: volume manager + filesystem digabung jadi satu layer, copy-on-write, checksum semua data, snapshot murah. Bedanya ada di cara mengelola disk: ZFS pakai struktur vdev yang kaku, Btrfs pakai chunk allocation yang fleksibel — tidak ada konsep vdev sama sekali.
flowchart TD
subgraph zfs["ZFS"]
ZD["Disk fisik"] --> VDEV["vdev<br/><small>mirror / raidz — struktur tetap</small>"]
VDEV --> ZPOOL["zpool"]
ZPOOL --> DS["Dataset / zvol"]
end
subgraph btrfs["Btrfs"]
BD["Disk fisik<br/><small>langsung, tanpa layer perantara</small>"] --> FS["Btrfs filesystem<br/><small>multi-device, RAID profile per chunk</small>"]
FS --> SV["Subvolume<br/><small>≈ dataset, mount point fleksibel</small>"]
SV --> SNAP["Snapshot<br/><small>subvolume juga, writable</small>"]
end# Satu command, langsung jadi: tidak ada pvcreate/vgcreate/zpool create bertingkat
mkfs.btrfs -d raid10 -m raid1 /dev/sd{a,b,c,d,e,f}
mount /dev/sda /mnt/data2. Mapping Mental Model: LVM vs ZFS vs Btrfs#
| Konsep | LVM | ZFS | Btrfs |
|---|---|---|---|
| Disk fisik | PV | disk dalam vdev | device, langsung ke filesystem |
| Unit redundancy | mdadm di bawah | vdev (struktur tetap) | chunk/block group (dinamis) |
| Kumpulan storage | VG | zpool | filesystem multi-device |
| Volume siap pakai | LV | dataset / zvol | subvolume |
| Block device (LUN) | LV | zvol | ❌ tidak ada padanan native |
| Snapshot | LVM snapshot (berat) | zfs snapshot (read-only) | btrfs snapshot (bisa writable) |
| Replikasi | — | zfs send/receive | btrfs send/receive |
Dua perbedaan paling penting vs ZFS:
- Tidak ada zvol — Btrfs tidak bisa meng-export block device. Untuk LUN iSCSI, NAS berbasis Btrfs memakai file image di atas filesystem (loopback) → overhead ekstra. Ini salah satu alasan QuTS hero (ZFS) lebih cocok untuk workload LUN VM.
- RAID profile per chunk, bukan per pool — data dan metadata bisa punya profil beda dalam satu filesystem (mis. data
raid10, metadataraid1).
3. Chunk Allocation — Inti Perbedaan dengan ZFS#
Btrfs membagi ruang disk menjadi chunk (block group, ~1 GB untuk data). Tiap chunk dialokasikan sesuai RAID profile-nya, dan penempatannya dinamis ke device mana pun yang punya ruang paling lega — bukan pasangan tetap.
flowchart TD
FS["Btrfs filesystem — profile data: raid1"]
FS --> C1["Chunk 1<br/><small>copy A + copy B</small>"]
FS --> C2["Chunk 2<br/><small>copy A + copy B</small>"]
FS --> C3["Chunk 3<br/><small>copy A + copy B</small>"]
C1 --> D1["disk1"]
C1 --> D2["disk2"]
C2 --> D2
C2 --> D3["disk3"]
C3 --> D1
C3 --> D3Perhatikan: chunk 1 di disk1+disk2, chunk 2 di disk2+disk3, chunk 3 di disk1+disk3 — tidak ada “pasangan mirror” tetap. raid1 di Btrfs artinya “2 copy di 2 device berbeda”, bukan “mirror disk A ke disk B”.
Konsekuensinya:
| Aspek | ZFS (vdev) | Btrfs (chunk) |
|---|---|---|
| Campur ukuran disk | Buruk — vdev dibatasi disk terkecil | Bagus — chunk mengisi disk besar lebih banyak |
| Tambah 1 disk ke RAID | Sulit (harus tambah vdev utuh) | btrfs device add + balance, selesai |
| Kurangi disk | Terbatas | btrfs device remove, chunk dipindah otomatis |
| Konversi RAID level online | ❌ | ✅ balance -dconvert=raid10 |
| Prediktabilitas performa | Tinggi (topologi tetap) | Lebih rendah (penempatan dinamis) |
Profil yang tersedia: single, dup (2 copy di 1 disk), raid0, raid1, raid1c3/c4 (3-4 copy), raid10, raid5, raid6.
⚠️ RAID5/6 di Btrfs sampai sekarang belum dianggap production-safe (write hole saat power loss + scrub/rebuild yang rawan). Untuk redundancy pakai
raid1/raid10. Ini beda dengan RAID-Z di ZFS yang solid.
4. Subvolume & Snapshot#
Subvolume = padanan dataset ZFS: pohon filesystem independen dengan snapshot sendiri, tapi berbagi space satu filesystem. Snapshot di Btrfs sebenarnya subvolume juga — makanya bisa writable (di ZFS harus lewat clone).
btrfs subvolume create /mnt/data/vm-images
btrfs subvolume list /mnt/data
# Snapshot (instan, copy-on-write)
btrfs subvolume snapshot /mnt/data/vm-images /mnt/data/.snap/vm-images-20260722
# Read-only snapshot (wajib untuk send/receive)
btrfs subvolume snapshot -r /mnt/data/vm-images /mnt/data/.snap/vm-images-ro
# "Rollback" = swap subvolume, bukan command rollback khusus
mv /mnt/data/vm-images /mnt/data/vm-images-broken
btrfs subvolume snapshot /mnt/data/.snap/vm-images-20260722 /mnt/data/vm-imagesReplikasi incremental, konsepnya identik zfs send:
flowchart LR
subgraph src["NAS utama"]
SV["subvolume vm-images"] --> R1["snap-1 (ro)"]
SV --> R2["snap-2 (ro)"]
end
subgraph dst["NAS backup"]
DEST["backup/vm-images"]
end
R1 -- "btrfs send (full)" --> DEST
R2 -- "btrfs send -p snap-1 (delta)" --> DEST5. Operasional Harian#
# Status & kapasitas — JANGAN pakai df biasa (menyesatkan di Btrfs)
btrfs filesystem usage /mnt/data # yang benar: raw vs usable per profile
btrfs device stats /mnt/data # error counter per device (≈ zpool status)
# Scrub — sama seperti ZFS, jadwalkan bulanan
btrfs scrub start /mnt/data
btrfs scrub status /mnt/data
# Balance — redistribusi chunk (tidak ada padanan di ZFS)
btrfs balance start -dusage=50 /mnt/data # rapikan chunk terisi <50%
btrfs balance status /mnt/data
# Ganti disk rusak
btrfs replace start /dev/sdc /dev/sdg /mnt/data
btrfs replace status /mnt/data
# Tambah / kurangi disk
btrfs device add /dev/sdh /mnt/data && btrfs balance start /mnt/data
btrfs device remove /dev/sdc /mnt/dataCatatan khas Btrfs yang sering menjebak:
- ENOSPC padahal “masih ada space” — space habis di level chunk metadata walaupun data belum penuh. Solusi: balance rutin (
-dusage=50) dan monitorfilesystem usage, bukandf. - Fragmentasi berat untuk file random-write besar (VM image, database) karena CoW. Mitigasi:
chattr +C(nodatacow) per direktori VM — tapi ini mematikan checksum & snapshot-consistency untuk file tsb. Trade-off yang tidak ada di ZFS zvol. - Quota (qgroups) mahal performa — aktifkan hanya jika benar-benar perlu.
6. Kaitannya dengan Pengalaman NAS Kamu#
Asustor ADM memakai Btrfs (di atas mdadm+LVM). Perilaku “volume locking saat cache penuh/SSD rusak” yang pernah kamu alami itu bukan sifat Btrfs-nya — itu desain write-back SSD cache di layer bawah milik vendor: dirty data hidup di SSD cache, SSD mati = filesystem di atasnya ikut tidak konsisten → vendor memilih lock volume.
Pelajaran arsitekturnya: yang menentukan aman/tidaknya cache bukan filesystem-nya, tapi di layer mana cache diletakkan dan apakah dia menahan dirty data. ZIL/L2ARC di ZFS aman karena by-design tidak pernah jadi satu-satunya pemilik data.
7. Kapan Pakai Apa#
| Kebutuhan | Pilihan |
|---|---|
| LUN iSCSI / block storage untuk VM | ZFS (zvol native) — Btrfs tidak punya |
| NAS file server, snapshot rutin, disk campur ukuran | Btrfs raid1/raid10 |
| Root filesystem Linux dengan snapshot boot (snapper) | Btrfs — integrasi distro terbaik (openSUSE, Fedora) |
| Redundancy parity (RAID5/6) | ZFS RAID-Z — Btrfs RAID5/6 belum aman |
| Storage terdistribusi multi-server, no-SPOF | Ceph |
| Sekadar volume management klasik tanpa CoW | LVM (+ mdadm/XFS) |
Untuk stack kamu: QNAP QuTS hero (ZFS) untuk LUN VM sudah tepat; Btrfs paling relevan kalau nanti ada kebutuhan file server Linux mandiri atau kamu ketemu NAS Asustor/Synology lagi — sekarang kamu tahu persis apa yang ada di baliknya.
8. Quick Reference#
mkfs.btrfs -d raid10 -m raid1 <devices> # buat filesystem multi-device
btrfs filesystem usage <mnt> # kapasitas yang benar
btrfs device stats <mnt> # error per disk
btrfs subvolume create <path> # subvolume baru
btrfs subvolume snapshot [-r] <src> <dst> # snapshot (writable / read-only)
btrfs send -p <snap-lama> <snap-baru> | btrfs receive <dst> # replika delta
btrfs scrub start <mnt> # verifikasi checksum
btrfs balance start -dusage=50 <mnt> # rapikan chunk
btrfs replace start <old> <new> <mnt> # ganti disk