Ringkasan Eksekutif

Saya baca RFC 18-patch dari Aurelien Desbrieres, pembuat BeamFS, yang menggantikan proposal filesystem sebelumnya (FTRFS) yang dia ajukan April lalu ke mailing list filesystem kernel Linux. Yang langsung menarik perhatian saya: dia bilang terang-terangan bahwa kode, tool pengecek patch, dan cover letter-nya ditulis dengan bantuan Claude, dan setiap patch dibubuhi tag Assisted-by sesuai kebijakan AI kernel — meski tanggung jawab kode tetap ada di tangan submitter manusia.

Masalah yang Diselesaikan

Filesystem yang bisa self-healing seperti Btrfs dan ZFS biasanya mengandalkan salinan cadangan data buat memperbaiki kerusakan. Masalahnya, menurut Aurelien, ada skenario di mana menyimpan salinan kedua itu bukan pilihan — misalnya komputer satelit yang cuma punya satu drive, atau komputer di ruang radioterapi yang datanya (termasuk data imaging dan rekam medis) bisa kena bit-flip dari radiasi neutron mesin terapi. Di konteks begini, byte yang salah tapi "terlihat normal" justru lebih bahaya daripada read yang gagal total, karena data buruk bisa lolos tanpa ketahuan.

Fitur Utama dan Contoh Kode

Alih-alih redundansi penuh, BeamFS menyimpan kode error-correction Reed-Solomon di dalam setiap block data. Setiap kali ada read, data itu dicek ulang terhadap kode tersebut: kerusakan kecil langsung dikoreksi sebelum sampai ke aplikasi, sementara kerusakan yang terlalu parah bikin read-nya gagal dengan error (bukan ngembalikan data yang salah). Dalam technical report Aurelien, dia menyimulasikan bit-flip pada data yang dibaca dari VM dan USB flash drive: ext4 dan ext3 diam-diam ngembalikan data salah, Btrfs menolak baca filenya, sedangkan BeamFS berhasil ngembalikan file yang benar di hampir semua kasus — kecuali sekali, waktu bit-flip kena pointer ke data file sehingga BeamFS ikut menolak baca. Dia sendiri mengingatkan ini bukan benchmark yang adil karena jumlah flip per filesystem berbeda-beda dan bukan dimaksudkan sebagai ranking.

Karena RFC ini belum punya API atau command publik yang terdokumentasi, berikut ilustrasi kasar (bukan dari sumber) bagaimana workflow-nya mestinya terlihat kalau sudah bisa dipakai:

# Ilustrasi, bukan contoh resmi dari proyek
mkfs.beamfs /dev/sdb1
mount -t beamfs /dev/sdb1 /mnt/data

# BeamFS belum punya journal, jadi fsck wajib dijalankan
# setelah unclean shutdown sebelum filesystem dipakai lagi
fsck.beamfs /dev/sdb1

Dampak dan Catatan Upgrade

Ini masih RFC, bukan request buat merge — Aurelien sendiri melempar dua pertanyaan ke maintainer: apakah BeamFS mesti jadi filesystem berdiri sendiri atau fitur ini diajukan ke filesystem yang sudah ada, dan soal journal. BeamFS belum punya journal (log buat recovery setelah crash) dan saat ini cuma mengandalkan fsck setelah unclean shutdown — dia nanya apakah journal ini wajib ada dulu sebelum review lanjut, atau bisa menyusul belakangan. Sejauh ini thread-nya baru dapat satu balasan, dan itu pun soal urutan alfabet entry MAINTAINERS, bukan soal teknis. README proyek ini juga udah wanti-wanti sendiri: ada bug yang bisa bikin data hilang, lubang keamanan, sampai crash kernel — jadi belum layak dipakai buat apa pun yang penting. Buat saya, ini layak dipantau karena pendekatannya beda dari self-healing filesystem yang ada, tapi belum ada yang perlu diupgrade atau diadopsi sekarang.

---

Pertama diumumkan di It's FOSS News. Baca sumber aslinya untuk detail lengkap.

Baca juga