Tunas Akara
Kembali ke Blog

Kenapa SD Card Cepat Mati di Perangkat Edge dan Cara Mendesain Sistemnya

oleh RayhanDiperbarui 8 menit baca
iotedgestoragelinuxreliability
Kenapa SD Card Cepat Mati di Perangkat Edge dan Cara Mendesain Sistemnya

Kenapa SD Card Cepat Mati di Perangkat Edge dan Cara Mendesain Sistemnya

Puluhan gateway Linux yang tersebar di banyak lokasi biasanya mulai menyisakan unit mati di bulan kedua belas sampai kedelapan belas. Gejalanya seragam. Perangkat masih bisa boot, filesystem berubah jadi read-only, lalu teknisi mengganti kartunya. Enam bulan kemudian kartu pengganti mengalami hal yang sama.

Kartunya tidak cacat dan lokasinya tidak luar biasa panas. Perangkatnya memang dirancang menulis terus-menerus ke media penyimpanan yang jatah tulisnya terbatas dan tidak bisa melaporkan sisa jatahnya. Ini masalah desain, dan biaya perbaikannya nyaris nol kalau diputuskan sejak awal.

Wear leveling cuma memutar blok yang Anda biarkan kosong

Sel NAND flash punya batas jumlah siklus hapus. Wear leveling adalah tugas controller menyebar siklus hapus itu supaya tidak ada satu blok yang mati duluan. Istilahnya satu, implementasinya dua, dan yang murah itulah yang dipakai microSD konsumer.

Wear leveling dinamis memutar tulisan ke blok yang sedang kosong. Wear leveling statis ikut memindahkan data dingin — kernel, binary, file yang ditulis sekali saat provisioning lalu tidak pernah disentuh lagi — supaya blok itu ikut giliran. SSD enterprise memakai leveling statis. Kartu harga lima dolar biasanya tidak.

Akibatnya menentukan umur perangkat Anda. Pada kartu 8 GB berisi root filesystem 6 GB, semua tulisan seumur hidup perangkat jatuh ke sisa 2 GB. Sisa 6 GB NAND yang masih sehat menganggur dan tidak menyerap apa pun.

Anggaran tulis yang tidak pernah dihitung

Hitung dulu sebelum deploy. Prosesnya dua menit dan hasilnya mengubah keputusan hardware.

Ambil contoh gateway yang menulis baris log 200 byte lima kali per detik. Itu 1 KB per detik, 86 MB per hari, sekitar 31 GB per tahun menurut hitungan host. Dibagi ruang rotasi 2 GB, angkanya cuma lima belas siklus penuh per tahun. Kelihatan aman.

Hitungan host bukan hitungan NAND. Write amplification adalah rasio antara byte yang ditulis aplikasi dan byte yang benar-benar diprogram ke flash. Pada kartu murah dengan blok hapus 4 MB, rasionya kejam.

Tulisan sinkron 200 byte tidak bisa mengubah 200 byte saja. Controller membaca satu blok utuh, menggabungkan perubahannya, memprogram ulang di tempat lain, lalu menandai blok lama untuk dihapus. Tambahkan commit journal ext4 tiap lima detik, metadata direktori, dan update mtime. Amplifikasi untuk tulisan kecil yang sinkron biasanya berada di rentang 10x sampai 100x.

Pada 50x, gateway yang sama mendorong sekitar 1.500 GB per tahun lewat ruang rotasi 2 GB. Anggap saja 750 siklus hapus per tahun. TLC 3D konsumer dinilai sekitar 1.000 siklus di level sel. Kartunya mati sekitar bulan kelima belas, persis saat laporan lapangan mulai masuk.

Tiga angka menentukan hasilnya, dan ketiganya ada di tangan Anda:

  • Byte yang ditulis per hari. Turunkan dengan batching dan dengan tidak memakai level log debug di produksi.
  • Ukuran ruang bebas. Naikkan dengan membeli kartu lebih besar lalu mempartisi sebagian saja.
  • Ketahanan sel. Beli kartu industrial yang punya angka TBW — Terabytes Written, total volume tulisan yang dijamin pabrik sebelum kartu aus — bukan kartu retail yang tidak punya angka apa pun.

Mati listrik merusak data yang Anda tulis berbulan-bulan lalu

Keausan itu kegagalan yang pelan. Mati listrik kegagalan yang cepat, dan kerusakannya bukan cuma file yang sedang terbuka.

Flash translation layer menyimpan peta dari alamat blok logis ke halaman NAND fisik, dan peta itu sendiri tinggal di flash. Putus listrik saat controller sedang memprogram halaman sekaligus memperbarui peta, dan kartu tanpa power-loss protection bisa kehilangan satu blok hapus utuh. Termasuk data yang ditulis jauh sebelum boot ini.

Journal filesystem Anda tidak pernah dilibatkan. Block device sudah menjawab sukses, lalu tetap membuang datanya.

Karena itu journal ext4 bukan jawaban seperti yang banyak orang kira. Mode bawaan data=ordered menjamin konsistensi metadata filesystem setelah crash. Mode ini tidak menjamin apa pun soal block device yang mengaku sukses lalu membatalkan tulisannya.

FAT32 masih jadi bawaan di banyak image vendor, dan FAT32 bahkan tidak punya journal. Mati listrik saat update tabel FAT bisa membuat separuh volume kehilangan induknya. Pola kegagalan inilah yang ada di balik sebagian besar pekerjaan recovery storage lapangan.

Kartu industrial punya kapasitor di dalamnya. Muatannya cukup untuk menyelesaikan operasi program yang sedang jalan dan menuliskan tabel pemetaannya. Kapasitor itulah bagian terbesar dari yang Anda bayar.

Desain: pindahkan tulisannya keluar dari kartu

Pola yang andal justru membosankan. Buat kartunya read-only saat operasi normal, lalu arahkan semua tulisan ke memori atau ke jaringan.

Loading diagram…

Rootfs read-only dengan overlay. Mount root filesystem sebagai read-only, lalu pasang overlay tmpfs di atasnya. Semua tulisan mendarat di RAM dan hilang saat reboot. Itu justru yang Anda mau untuk perangkat yang state aslinya hidup di server.

Di Raspberry Pi OS pilihan ini sudah ada di raspi-config. Di image custom, bentuknya overlayroot atau hook initramfs kecil. Proses yang keras kepala menulis ke /var tetap jalan, cuma tulisannya masuk ke RAM.

Log ke tmpfs, lalu keluar dari perangkat. Set Storage=volatile dan batas RuntimeMaxUse di journald.conf, lalu forward ke log server pusat. Kuncinya ada di ukuran tmpfs-nya. Terlalu kecil, konteks buat debugging hilang. Terlalu besar, satu proses cerewet memicu OOM killer. Mulai dari 64 MB masuk akal untuk perangkat RAM 1 GB.

Batch telemetri, jangan append. Loop sensor yang menulis satu baris per pembacaan lalu sync tiap kali adalah pola paling buruk untuk flash. Tampung di memori, tulis sekali per menit, dan terima risiko kehilangan enam puluh detik data saat crash.

Kalau datanya tidak boleh hilang, pakai file spool yang Anda tulis ulang utuh, bukan file yang terus di-append. Prinsipnya sama dengan pembaca meter berbasis kamera yang mengirim frame ke server dan tidak menyimpan riwayat lokal.

Opsi mount untuk partisi yang tetap bisa ditulis. noatime menghapus satu tulisan metadata setiap kali ada pembacaan. commit=60 di ext4 mengumpulkan commit journal jadi satu menit sekali, bukan lima detik sekali. Anda menukar jendela kehilangan data yang lebih lebar dengan siklus hapus yang jauh lebih sedikit. Keduanya cuma satu baris di /etc/fstab.

Overprovision dengan mempartisi pendek. Beli kartu 32 GB, buat partisi 8 GB, sisanya biarkan tidak terpakai. Blok yang tidak pernah ditulis tetap ada di ruang bebas controller dan melipatgandakan ruang rotasi.

Jalankan blkdiscard ke seluruh device sebelum mempartisi supaya controller tahu ruangnya kosong. Ini perubahan paling murah dari semua daftar di atas.

Kalau kartunya memang harus tetap dipakai

Tidak semua desain bisa pindah ke eMMC, dan eMMC yang disolder di board orang lain punya jebakannya sendiri. Saat kartu lepasan jadi keharusan, ada tiga hal di datasheet yang layak dibaca.

Mode pSLC. Kartu industrial menjalankan NAND TLC 3D dalam mode pseudo-SLC, menyimpan satu bit per sel, bukan tiga. Kapasitasnya turun jadi sekitar sepertiga, ketahanannya naik sekitar 20x — dari kisaran 1.000 siklus ke 20.000 atau lebih. Kartu pSLC 8 GB dan kartu TLC 32 GB bisa dibangun dari silikon yang sama persis.

Angka TBW atau siklus P/E yang benar-benar ada. Kartu retail memasang speed class dan rating IOPS A2. Keduanya menjelaskan kecepatan, bukan umur. Kalau datasheet-nya tidak menyebut terabytes written atau siklus program/erase, vendornya belum berkomitmen ke angka apa pun. Anda juga tidak punya angka untuk dihitung.

Power-loss protection. Harus disebut eksplisit di datasheet, biasanya sebagai kapasitor onboard atau FTL power-fail-safe.

Selisih harganya kelihatan menyakitkan di bill of materials, lalu hilang di lapangan. Kartu industrial harganya beberapa kali lipat kartu retail. Satu kali kunjungan teknisi ke lokasi untuk ganti kartu sudah lebih mahal dari selisih itu.

Health check supaya Anda tahu sebelum teknisi berangkat

SD card tidak punya SMART. Itu titik awal yang jujur. Sisa umur kartu SD standar memang tidak bisa ditanyakan seperti pada SSD. Tiga sinyal berikut sudah menutup sebagian besar kebutuhannya.

Kesehatan eMMC, kalau perangkat Anda memakai eMMC. Register EXT_CSD membawa PRE_EOL_INFO dan DEVICE_LIFE_TIME_EST_TYP_A/B, dan mmc-utils bisa membacanya:

mmc extcsd read /dev/mmcblk0 | grep -iE 'PRE_EOL|LIFE_TIME'

Nilai PRE_EOL_INFO 0x02 berarti blok cadangan sudah terpakai 80 persen. Nilai 0x03 berarti 90 persen. Estimasi umurnya datang dalam kelipatan 10 persen. Poll mingguan dan pasang alert saat nilainya berubah. Ini satu-satunya peringatan dini yang nyata di kategori penyimpanan ini.

Remount read-only. Saat kernel kena I/O error, filesystem-nya di-remount jadi read-only. Perangkatnya biasanya tetap jalan dalam kondisi cacat, dan tidak ada yang sadar sampai datanya dibutuhkan.

Cek output mount untuk flag ro di partisi data tiap beberapa menit, lalu alert langsung. Satu cek ini mengubah kegagalan senyap jadi kunjungan terjadwal. Tempatnya di setup monitoring minimal yang sama dengan probe uptime Anda.

File canary. Tulis pola 1 MB yang sudah diketahui isinya saat provisioning, baca ulang tiap minggu, bandingkan checksum-nya. Murah, menangkap korupsi senyap, dan memberi Anda bukti saat vendor bilang kartunya baik-baik saja.

Pesan kernel jadi sinyal keempat dan gratis untuk di-grep. mmc0: error -110, I/O error, dan EXT4-fs error di dmesg sama-sama berarti kartu sedang menuju akhir. Forward semuanya bersama log Anda, lalu cocokkan polanya di pusat.

Ringkasnya

Anggap kartunya pasti aus, lalu desain sistemnya supaya keausan itu tidak penting. Rootfs read-only, log di RAM dan dikirim keluar perangkat, telemetri dibatch bukan di-append, partisi jauh lebih kecil dari kapasitas kartu, dan kartu industrial dengan power-loss protection saat anggaran mengizinkan.

Setelah itu pasang instrumen untuk kegagalan yang tidak sempat Anda cegah. Perangkat yang melapor remount read-only hari Selasa itu tiket maintenance. Perangkat yang sama ditemukan mati bulan Maret, memegang tiga bulan data yang tidak terbaca, itu insiden.

Artikel Terkait

Mau bangun hal serupa?

Jasa Pengembangan Backend IoT & Integrasi Multi-Protokol

Backend yang menyerap telemetri perangkat lintas MQTT, WebSocket, Modbus, dan BLE, lalu menyatukannya jadi dashboard real-time yang andal.

Lihat cara saya bisa bantu