Batas praktis jumlah snapshot btrf?


23

Saya sedang mempertimbangkan untuk menggunakan btrf pada drive data saya sehingga saya dapat menggunakan kakap , atau sesuatu seperti kakap, untuk mengambil foto berdasarkan waktu. Saya percaya ini akan membiarkan saya menjelajahi versi lama data saya. Ini akan menjadi tambahan cadangan situs saya saat ini karena kegagalan drive akan menghapus data dan snapshot.

Dari pemahaman saya, btrfs snapshots tidak memakan banyak ruang (meta data dan blok yang telah berubah, ditambah mungkin beberapa overhead), jadi ruang sepertinya tidak menjadi kendala.

Jika saya memiliki sejuta snapshot (mis., Snapshot setiap menit selama dua tahun) apakah itu akan menyebabkan malapetaka, dengan asumsi saya memiliki cukup ruang disk untuk data, data yang diubah, dan data meta?

Jika ada batasan praktis pada jumlah foto, apakah itu tergantung pada jumlah file dan / atau ukuran file?

Jawaban:


16

Sebagai seseorang yang menggunakan btrfssistem file Arch Linuxhampir selama 2bertahun-tahun sekarang saya dapat dengan aman mengatakan bahwa sepertinya tidak ada batasan praktis pada jumlah foto yang dapat dengan mudah dicapai. Namun ada beberapa peringatan. btrfsfilesystem dapat menyebabkan fragmentasi. Karena itu, disarankan untuk menggunakan fitur defragmentasi daring yang ada di dalamnya btrfs. Selain itu, orang dapat memanfaatkan btrfsfitur kompresi. Langkah-langkah ini harus menangani sebagian besar masalah kinerja yang dapat muncul pada komputer yang cukup layak dari membuat banyak snapshot.

Seperti yang Anda ketahui btrfsmemperlakukan subvolume sebagai sistem file dan karenanya jumlah snapshot memang terbatas: yaitu berdasarkan ukuran file. Menurut btrfswiki, ukuran file maksimum yang bisa dihubungi adalah 2^64 byte == 16 EiB[1] .

Selain dari keterbatasan ini, selalu ada masalah ketika Anda kehabisan ruang tanpa Anda sadari karena memeriksa ruang kosong pada btrfssistem file kadang-kadang bisa rumit, yaitu tanpa bisa membedakan antara berbagai metode pengukuran ruang kosong pada btrfssistem file yang bisa dilakukan. dengan mudah menggunakan jejak berapa jumlah ruang yang tersisa. Salah satu cara yang mungkin untuk mencegah skenario ini adalah penggunaan kuota. Ini memastikan bahwa pengguna (atau pengguna jika hanya satu) hanya dapat menggunakan sejumlah ruang tertentu. Konsep ini dibahas sangat cakap di sini dan juga di sini .

Terakhir, namun tidak kalah pentingnya, peringatan: Saya bukan pakar btrfssistem file dan hanya membaca tentang hal-hal ini ketika saya memiliki pertanyaan yang sama beberapa waktu lalu. Selain itu, selalu ada masalah yang btrfsmerupakan "target bergerak cepat" ( Arch Linuxsaya kira kata-kata dicuri dari halaman wiki.) Sehingga segala sesuatunya mungkin berubah.


1
Saya salah satu dari mereka yang mengadopsi sebelumnya, dan ini sangat baik.
mikeserv

Yap lumayan banget :)
Mark K Cowan

1
Anda harus mencoba untuk tetap di bawah 100 foto pada satu volume BTRFS. Kalau tidak, Anda mungkin mengalami masalah kinerja, terutama pada menghapus snapshot. Membuat foto adalah berbiaya rendah, tetapi menghapusnya tidak. Juga, perhatikan bahwa rekomendasi untuk melakukan defragmentasi bersama dengan menggunakan snapshots akan menghilangkan efisiensi ruang dari snapshots. Defragging memecah reflink dan mengalikan ruang yang digunakan.
MountainX untuk Monica Cellio

@MountainX dapat Anda uraikan ini dalam sebuah jawaban. 100 foto pada volume bahkan tidak satu minggu selama dua tahun.
StrongBad

@ StrongBad - Saya menerima info itu dari milis BTRFS sebagai jawaban atas masalah. Semua orang sepakat bahwa memiliki ratusan atau ribuan foto adalah ide yang buruk. Untuk jawaban yang lebih teknis, Anda harus bertanya pada milis BTRFS.
MountainX untuk Monica Cellio

5

Meskipun secara teknis tidak ada batasan jumlah foto, saya bertanya pada milis BTRFS :

Jawaban (praktis) tergantung sampai batas tertentu pada bagaimana Anda menggunakan btrfs.

Btrf memang memiliki masalah penskalaan karena terlalu banyak snapshot (atau sebenarnya snapshot reflink yang digunakan, dedup menggunakan reflink dapat memicu masalah penskalaan yang sama), dan foto tunggal hingga dua digit dari snapshot per subvolume snapshotted tetap menjadi rekomendasi kuat karena alasan itu.

Tetapi masalah penskalaan terutama memengaruhi perintah pemeliharaan btrfs sendiri, menyeimbangkan, memeriksa, menghapus subvolume. Sementara jutaan snapshot akan membuat keseimbangan, misalnya, secara efektif tidak dapat bekerja (itu akan menyortir tetapi bisa memakan waktu berbulan-bulan), operasi sistem file normal seperti membaca dan menyimpan file cenderung tidak terpengaruh, kecuali sejauh fragmentasi menjadi masalah ( sistem file sapi seperti btrf dicatat untuk fragmentasi, kecuali langkah-langkah seperti defrag diambil untuk menguranginya).

Tampaknya menggunakan snapshot sebagai cadangan arsip yang mirip dengan mesin waktu / kakap bukanlah ide yang baik.


Time Machine bukan cadangan arsip, ini cadangan. Saya tidak membagikan kesimpulan Anda. Menggunakan snapshot btrf dapat menjadi ide yang sangat bagus untuk Time Machine seperti backup (karena kernel Linux tidak dapat menautkan direktori, sehingga menyebabkan untuk membuat ulang struktur direktori lengkap untuk setiap snap, yang dapat menyebabkan penggunaan ruang disk yang cukup besar). Untuk cadangan pada satu perangkat cadangan, tanpa ingin menambahkan perangkat tambahan, bahkan tidak ada tujuan dalam menjalankan perintah keseimbangan. Jawaban daftar btrf juga mencoba menjelaskan ini.
Cadangan Pro

@ ProBackup, jawaban daftar btrfs mengatakan, jaga agar jumlah snapshot tetap tunggal hingga rendah, yang sebenarnya tidak dilakukan oleh default lengkungan untuk kakap . Meskipun btrfs-balance tidak diperlukan untuk pengaturan sederhana, banyak pengguna menyukai gagasan btrfs-check, bahkan jika mereka tidak membutuhkannya, dan penghapusan subvolume tampaknya penting jika Anda ingin memutar subvolume seperti yang dilakukan kakap.
StrongBad

Cadangan arsip @ProBackup mungkin bukan istilah yang tepat untuk Time Machine. Sepertinya mesin waktu lebih dari sekedar cadangan inkremental, tapi saya tidak nyaman menyebutnya sebagai backup berbasis snapshot seperti snapper atau rsnapshot, tapi mungkin itu akan lebih baik. Senang bagi Anda untuk mengedit istilah karena sepertinya Anda tahu banyak tentang bidang ini.
StrongBad

Dari apa yang saya baca di beranda kakap, kakap bukanlah alat cadangan. Meskipun kakap dapat kembali ke masa lalu, tidak berarti itu seperti Time Machine. Perbedaan mendasarnya adalah Time Machine menyimpan salinan semua data sebagai media yang terpisah, di mana kakap bahkan mungkin tidak membuat salinan.
Pro Backup

@ ProBackup akhirnya, tolong tulis jawaban dan jelaskan mengapa kesimpulan saya tentang jawaban di milis salah. Dengan begitu kita bisa melihat bagaimana perasaan masyarakat.
StrongBad

3

Anda dapat memiliki total gabungan 2 64 foto dan subvolume.

The btrfsdesain halaman wiki mengatakan (saya empahsis):

Subvolume pada dasarnya adalah btree bernama yang menyimpan file dan direktori. Mereka memiliki inode di dalam pohon akar pohon dan dapat memiliki pemilik dan kelompok non-root. Subvolume dapat diberikan kuota blok, dan begitu kuota ini tercapai, penulisan baru tidak diizinkan. Semua blok dan ekstensi file di dalam subvolume adalah referensi yang dihitung untuk memungkinkan snapshotting. Hingga 2 64 subvolume dapat dibuat di FS.

Snapshots identik dengan subvolume , tetapi blok root mereka awalnya dibagikan dengan subvolume lain. Ketika snapshot diambil, jumlah referensi pada blok root meningkat, dan sistem transaksi copy on write memastikan perubahan yang dibuat dalam snapshot atau sumber subvolume bersifat pribadi untuk root tersebut. Snapshots dapat ditulis, dan mereka dapat snapshotted lagi beberapa kali. Jika hanya bidikan snapshot yang diinginkan, kuota pemblokirannya diatur menjadi satu pada waktu pembuatan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.