Sinkronkan berkas

Pertanyaan

Gimana menyinkronkan berkas besar antar perangkat dengan mengirim sesedikit mungkin, tanpa kehilangan perubahan, dan tanpa menghapus data yang masih dipakai?

Setelah baca ini, kamu bisa merancang model blok dan revisi, menjelaskan cara mendeteksi konflik, dan menentukan kapan blok boleh dihapus.

Prasyarat dan contoh

Kamu sudah paham checksum dan unggahan (M15.01), penyimpanan tahan lama (M09), dan idempotensi (M03).

Pengguna mengedit satu berkas presentasi 200 MB. Mengubah satu slide hanya mengubah sekitar 2 MB isinya. Kalau tiap simpan mengunggah ulang 200 MB, 20 kali simpan per hari menghabiskan 4 GB per pengguna. Kalau dua perangkat mengedit berkas yang sama secara offline, salah satu hasil edit bisa hilang diam-diam kalau sistem hanya memakai "yang terakhir menang".

Mekanisme

Pecah jadi blok bernama hash. Berkas dipotong menjadi blok (misalnya 4 MiB tetap, atau potongan berbasis isi supaya penyisipan di tengah tidak menggeser semua batas). Tiap blok diberi nama dari hash isinya (SHA-256). Konsekuensinya: blok identik tersimpan sekali, dan klien bisa bertanya "blok mana yang belum kamu punya?" sebelum mengunggah.

Revisi adalah daftar blok berurutan. Satu revisi berkas berisi daftar [hash1, hash2, ..., hashN] plus metadata (ukuran, waktu, perangkat asal, revisi induk). Revisi bersifat immutable: mengedit berarti membuat revisi baru dengan induk revisi lama. Presentasi 200 MB = 50 blok 4 MiB. Setelah mengubah satu slide, mungkin 1 sampai 2 blok berubah, jadi unggahan hanya 4 sampai 8 MiB, sisanya sudah ada.

rev-7: [a1, b2, c3, d4, ...]      induk: rev-6
rev-8: [a1, b2, c9, d4, ...]      induk: rev-7   (hanya c3 → c9 yang diunggah)

Urutan penerbitan. Unggah semua blok dulu dan verifikasi hash-nya, baru tulis revisi, baru geser penunjuk "revisi terkini". Kalau urutannya terbalik, perangkat lain bisa melihat revisi yang merujuk blok yang belum ada. Penggeseran penunjuk dilakukan dengan operasi kondisional: "ubah kepala dari rev-7 ke rev-8 hanya jika kepala sekarang rev-7".

Konflik. Dua perangkat sama-sama mengedit dari rev-7 dan menghasilkan rev-8a dan rev-8b. Penunjuk kondisional membuat penulis kedua gagal, dan itu justru tujuannya: konflik terdeteksi, bukan tertimpa. Pilihan penanganan:

• Simpan keduanya: rev-8b diberi nama "berkas (konflik dari perangkat B)". Aman, merepotkan pengguna.
• Gabung otomatis: hanya masuk akal jika format berkas dipahami (teks per baris, dokumen terstruktur). Untuk biner buram, jangan menebak.
• Last-writer-wins: sederhana, tapi menghilangkan perubahan. Pakai hanya kalau kehilangan itu memang diterima, dan catat revisi yang kalah supaya masih bisa dipulihkan.

Garbage collection. Blok yang nggak dirujuk revisi mana pun adalah sampah, tapi menghapusnya berbahaya, karena unggahan yang sedang berjalan baru saja mengirim blok sebelum revisinya ditulis. Pola aman: pelacakan referensi atau mark-and-sweep. Mark: telusuri semua revisi yang dipertahankan dan kumpulkan blok yang dirujuk. Sweep: hapus blok yang nggak ditandai dan lebih tua dari masa tenggang (misalnya 24 jam), supaya blok dari unggahan yang belum selesai nggak ikut terhapus. Retensi revisi (simpan 30 hari atau 100 revisi) menentukan seberapa banyak yang bisa dibersihkan.

Saat rancangan ini gagal

• Blok dihapus yang masih dirujuk. GC berjalan saat revisi baru belum tercatat, atau menghitung referensi dari data yang usang. Berkas terbuka lalu gagal karena blok ke-17 hilang. Masa tenggang dan GC dua fase menjadi pengaman.
• Hash yang nggak diverifikasi. Server percaya klien bahwa blok bernama a1 memang berhash a1. Klien jahat atau korup bisa meracuni blok yang dipakai orang lain. Server menghitung ulang hash saat blok diterima.
• Deduplikasi lintas pengguna membocorkan informasi. Kalau klien bisa bertanya "blok dengan hash ini sudah ada?", ia bisa menebak apakah orang lain menyimpan berkas tertentu. Batasi dedup ke dalam satu akun atau tenant, atau terima risikonya dengan sadar.
• Batas blok bergeser. Blok tetap 4 MiB membuat penyisipan 1 byte di awal mengubah semua blok setelahnya. Chunking berbasis isi mengurangi masalah ini, dengan kompleksitas tambahan.
• Riwayat tumbuh tanpa batas. Tanpa retensi, revisi lama menahan blok selamanya dan biaya penyimpanan terus naik.

Latihan

Pengguna A dan B mengedit berkas 120 MB (30 blok 4 MiB) dari rev-5 secara offline. A mengubah blok 3 dan menghasilkan rev-6a. B mengubah blok 20 dan menghasilkan rev-6b. A sinkron lebih dulu, lalu B. Jelaskan apa yang terjadi saat B sinkron, berapa byte yang diunggah masing-masing, dan kapan blok lama blok 3 boleh dihapus.

Lihat pembahasan+

Unggahan: A mengunggah 1 blok baru (4 MiB), B juga 1 blok (4 MiB). Server menanyakan blok mana yang belum dimiliki, dan 29 blok lainnya sudah ada.

Saat A sinkron: penunjuk kepala berubah dari rev-5 ke rev-6a dengan operasi kondisional. Berhasil.

Saat B sinkron: B mencoba mengubah kepala dari rev-5 ke rev-6b, tapi kepala sekarang rev-6a, jadi operasi kondisional ditolak. Server mengembalikan konflik. Karena kedua revisi punya induk yang sama (rev-5) dan mengubah blok yang berbeda (3 dan 20), format berkas yang dipahami bisa digabung otomatis menjadi rev-7 dengan blok 3 dari A dan blok 20 dari B. Kalau berkas biner buram dan penggabungan tidak aman, simpan rev-6b sebagai salinan konflik dan minta pengguna memilih. Tidak ada edit yang hilang.

Blok lama blok 3 (milik rev-5) tetap dirujuk rev-5. Ia baru boleh dihapus kalau rev-5 sudah keluar dari retensi (misalnya lebih tua dari 30 hari dan bukan induk revisi yang dipertahankan) dan tidak ada revisi lain yang merujuknya, dan setelah lewat masa tenggang GC. Jawaban yang baik menyebut pembaruan kondisional, tidak menimpa diam-diam, dan GC dengan masa tenggang.

Terkait

• Sebelumnya: Unggah langsung ke penyimpanan (M15.01) membahas checksum dan pembersihan unggahan yang sama dasarnya dengan blok di sini.
• Konsistensi dan konflik tulis dibahas lebih luas di modul replikasi dan konsistensi (M08).
• Pilih arsitektur media langsung (M15.06) menutup modul ini.
• Rancangan D18, proyek B11, dan lab L15 belum tersedia.

Catatan

• Asumsi: penyimpanan objek yang menjamin blok immutable dan satu tempat yang bisa melakukan pembaruan kondisional untuk penunjuk kepala.
• Yang nggak dibahas: CRDT dan penggabungan dokumen kolaboratif real-time, enkripsi ujung ke ujung, dan sinkronisasi izin berbagi.
• Ukuran blok 4 MiB adalah contoh. Ukuran sebenarnya adalah kompromi antara overhead metadata dan efisiensi dedup.
• Terakhir ditinjau: 26 Oktober 2026.