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/data

2. Mapping Mental Model: LVM vs ZFS vs Btrfs#

KonsepLVMZFSBtrfs
Disk fisikPVdisk dalam vdevdevice, langsung ke filesystem
Unit redundancymdadm di bawahvdev (struktur tetap)chunk/block group (dinamis)
Kumpulan storageVGzpoolfilesystem multi-device
Volume siap pakaiLVdataset / zvolsubvolume
Block device (LUN)LVzvol❌ tidak ada padanan native
SnapshotLVM snapshot (berat)zfs snapshot (read-only)btrfs snapshot (bisa writable)
Replikasizfs send/receivebtrfs send/receive

Dua perbedaan paling penting vs ZFS:

  1. 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.
  2. RAID profile per chunk, bukan per pool — data dan metadata bisa punya profil beda dalam satu filesystem (mis. data raid10, metadata raid1).

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 --> D3

Perhatikan: 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:

AspekZFS (vdev)Btrfs (chunk)
Campur ukuran diskBuruk — vdev dibatasi disk terkecilBagus — chunk mengisi disk besar lebih banyak
Tambah 1 disk ke RAIDSulit (harus tambah vdev utuh)btrfs device add + balance, selesai
Kurangi diskTerbatasbtrfs device remove, chunk dipindah otomatis
Konversi RAID level onlinebalance -dconvert=raid10
Prediktabilitas performaTinggi (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-images

Replikasi 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)" --> DEST

5. 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/data

Catatan khas Btrfs yang sering menjebak:

  1. ENOSPC padahal “masih ada space” — space habis di level chunk metadata walaupun data belum penuh. Solusi: balance rutin (-dusage=50) dan monitor filesystem usage, bukan df.
  2. 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.
  3. 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#

KebutuhanPilihan
LUN iSCSI / block storage untuk VMZFS (zvol native) — Btrfs tidak punya
NAS file server, snapshot rutin, disk campur ukuranBtrfs 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-SPOFCeph
Sekadar volume management klasik tanpa CoWLVM (+ 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