BTRFS untuk yang terkecil

Selamat siang, Khabravchane. Saya bekerja di Veeam Software dan saya adalah salah satu pengembang solusi cadangan Linux kami. Berdasarkan pekerjaan, saya kebetulan bertemu BTRFS. Baru-baru ini, telah beralih dari status "belum cocok" ke status "stabil". Dan sementara pengguna pertamanya di jaringan mendiskusikan masalah area dan masalah stabilitas, kami di Veeam menyodoknya dengan tongkat dan mencoba untuk mencadangkannya. Ternyata, secara halus, tidak terlalu banyak - itu terlalu berbeda, tidak seperti sistem file tradisional. Saya harus mempelajari banyak aspek dan mengumpulkan banyak garu sebelum kami belajar bagaimana cara menggunakannya. Dalam proses belajar, BTRFS berhasil membuat saya terkesan, baik dengan cara yang baik maupun tidak. Saya yakin dia tidak akan meninggalkan acuh tak acuh spesialis IT dari dunia Linux: beberapa akan meludah, yang lain akan memuji.

Jika Anda pernah mendengar tentang sistem file ini, tetapi tidak tahu mengapa, tertarik pada detailnya, atau mencari di mana harus mulai mengetahuinya, saya mengundang Anda ke kucing.

Pendahuluan


BTRFS (B-Tree Filesystem) - sistem file untuk sistem operasi mirip Unix, berdasarkan teknik Copy on Write (CoW), yang dirancang untuk memberikan kemudahan penskalaan sistem file, keandalan dan keamanan data tingkat tinggi, fleksibilitas konfigurasi dan kemudahan administrasi, dengan tetap mempertahankan pada saat yang sama kecepatan tinggi. Setidaknya itulah yang dikatakan halaman utama wiki .

Untuk mematuhi formalitas, kami mencantumkan fitur utama btrf:

  • Ukuran file maksimum 2 ^ 64 byte
  • Tabel inode dinamis
  • Deduplikasi data
  • Penyimpanan file yang efektif baik ukurannya sangat kecil dan sangat besar
  • Membuat Subwolums dan Snapshots
  • Subvolume Quota
  • Checksum untuk data dan metadata
  • Kemampuan untuk menggabungkan beberapa drive menjadi satu sistem file
  • Membuat konfigurasi RAID di tingkat sistem file
  • Kompresi data
  • Defragmentasi data dengan cepat

Saya ingin segera memperingatkan Anda bahwa BTRFS sedang aktif berkembang, dan beberapa poin mungkin berbeda dari versi ke versi. Tautan - https://btrfs.wiki.kernel.org/index.php/Changelog, Anda dapat mengetahui kapan fungsionalitas ditambahkan, diubah, atau diperbaiki.

Ya, BTRFS adalah sistem file muda dan modern yang menyelesaikan berbagai tugas, tetapi tidak tanpa kekurangannya:

  • Pengembangan aktifnya mengarah pada perubahan pada poin-poin penting yang dapat diandalkan utilitas pihak ketiga saat bekerja dengannya.
  • Meskipun ada jaminan dari pengembang tentang stabilitas BTRFS, pengguna secara teratur menghadapi masalah yang berpotensi menyebabkan hilangnya data. Sebagai aturan, mereka "mengambang" di alam, sebagai akibatnya mereka belum dipelajari dan diperbaiki.
  • Kerentanan tinggi terhadap fragmentasi.
  • Dokumentasi yang minim dan terkadang ketinggalan jaman.

Seluruh halaman dikhususkan untuk masalah sistem file pada versi yang berbeda dari kernel - https://btrfs.wiki.kernel.org/index.php/Gotcha . Saya sangat menyarankan Anda untuk melihat di sana - ternyata banyak yang menarik dan tidak jelas.

Struktur BTRFS


Perangkat BTRFS yang disederhanakan dapat dibagi ke dalam level berikut:



Perangkat blok terletak di tingkat terendah, mewakili satu atau beberapa ruang alamat fisik yang terpisah ("fisik" yang sama dengan perangkat blok itu sendiri, tetapi ini sudah detail). Melalui struktur khusus, blok memori fisik yang dialokasikan digabungkan menjadi satu ruang alamat virtual.

Struktur dan blok metadata dengan data pengguna (luasan) sudah ditangani pada tingkat logis. Akibatnya, data yang ditempatkan secara berurutan pada tingkat logis dapat secara fisik berada pada perangkat blok yang berbeda.

Struktur metadata dapat dibagi menjadi beberapa tingkatan. Tentu saja, saya tidak akan mengklasifikasikan mereka - ada banyak dari mereka, dan rincian tingkat rendah seperti itu adalah topik dari artikel terpisah. Penting di sini bahwa beberapa struktur dalam hierarki akan berubah menjadi tingkat yang lebih tinggi daripada yang lain, dan di bagian paling atas akan ada struktur yang merupakan subvolume.

Subvolume adalah semacam titik masuk, atau lebih tepatnya, elemen root dari sistem file. Mereka membentuk lapisan representasi data yang terpisah, yang merangkum pekerjaan lapisan bawah, menyajikan data pengguna dalam bentuk biasa: direktori dan file. Selain itu, subwolves adalah elemen kunci dari mekanisme KK pada BTRFS. File yang sama dalam dua subvolume mungkin berubah menjadi set data yang sama di tingkat bawah.

Lapisan terakhir adalah lapisan data. Seperti yang dilihat pengguna. Ini adalah file dan direktori yang terletak di subvolume.

Tapi cukup teori. Sudah waktunya untuk melanjutkan berlatih!

Btrfs-prog


Ini adalah seperangkat utilitas standar untuk mengelola BTRFS. Bergantung pada paket distribusi, paket dengan utilitas ini di repositori mungkin memiliki nama yang berbeda: btrfsprogs , btrfs-progs , btrfs-tools , dll. Jika repositori Anda tidak memiliki yang serupa, Anda selalu dapat mengompilasinya secara manual, sumbernya tidak jauh - https://github.com/kdave/btrfs-progs .
Utilitas yang paling penting dalam paket ini adalah btrfs dan mkfs.btrfs . Dari yang kedua, saya pikir, semuanya sangat jelas - perlu untuk membuat BTRFS pada perangkat blok. Pertama, btrfs adalah utilitas utama yang memungkinkan Anda melakukan sisanya. Semacam "pisau Swiss."

Pada artikel ini, saya menggunakan versi v4.15.1. Utilitas berkembang sangat aktif, dan ada perbedaan nyata dari versi ke versi. Jadi jika Anda tidak memiliki perintah yang diperlukan, periksa versi utilitas btrf , mungkin sudah ketinggalan zaman.

Juga, kemungkinan besar, utilitas btrfsck dan btrfstune ditemukan dalam paket.

  • Yang pertama dari mereka berfungsi untuk memeriksa kesalahan sistem file dan untuk koreksi selanjutnya, namun, saya tidak merekomendasikan menggunakannya - itu dalam status usang , fungsinya telah dipindahkan ke perintah cek btrfs .
  • Yang kedua memungkinkan Anda untuk melakukan beberapa operasi yang bermanfaat pada btrfs, misalnya, mengubah pengidentifikasi unik sistem file (FS UUID), atau mengaktifkan fungsionalitas tertentu dari sistem file.

Selain utilitas yang tercantum di atas, ada beberapa utilitas lagi dalam paket, tetapi mereka terutama diperlukan untuk debugging btrfs dan tidak akan berguna bagi kami dalam artikel ini.

Memformat disk di BTRFS


Dalam praktiknya, semuanya lebih sederhana. Mari kita mulai dengan satu drive.
Memformat disk tunggal dalam btrfs terjadi dengan perintah biasa:

mkfs.btrfs /dev/sdc -L single_drive 

Sebagai tanggapan, utilitas akan menampilkan parameter sistem file yang dibuat ke konsol:

 btrfs-progs v4.15.1 See http://btrfs.wiki.kernel.org for more information. Label:       single_drive UUID:        59307d69-6d2f-4d2e-aae2-a5189ad3c256 Node size:     16384 Sector size:    4096 Filesystem size:  1.00GiB Block group profiles: Data:       single 8.00MiB Metadata:     DUP 51.19MiB System:      DUP 8.00MiB SSD detected:    no Incompat features: extref, skinny-metadata Number of devices: 1 Devices:  ID    SIZE PATH   1   1.00GiB /dev/sdc 

Mari kita lihat parameter yang disajikan.

  • Label - Label atau nama sistem file. Ini ditentukan oleh saklar -L dan merupakan parameter opsional.
  • UUID adalah pengidentifikasi unik yang membuat kernel btrf membedakan instance dari satu sama lain.
  • Ukuran simpul - ukuran elemen B-tree tempat metadata disimpan. Ini dapat diatur menggunakan -n | --nodesize -n | --nodesize , dan itu harus kelipatan dari ukuran ukuran Sektor . Ukuran simpul yang kecil menyebabkan peningkatan ketinggian pohon-B (peningkatan jumlah simpul) dan, sebagai akibatnya, terjadi penurunan kompetisi untuk memblokir simpul individu. Di sisi lain, ukuran simpul yang kecil membuat instance sistem file lebih rentan terhadap fragmentasi. Node besar, di sisi lain, berkontribusi pada pengemasan metadata yang lebih baik pada disk, yang mengurangi fragmentasi.
    Kelemahannya adalah peningkatan waktu akses data untuk memperbarui simpul yang sama dengan banyak utas. Pada kernel yang lebih tua dari 3.11, secara default, ukuran node adalah 16384 byte atau ukuran halaman memori OS (lebih besar dari kedua nilai ini).
  • Ukuran sektor - jumlah ruang yang merupakan kelipatan dari ruang mana yang dialokasikan dan dibebaskan pada tingkat fisik. Ini sama dengan ukuran halaman dari memori virtual OS, kecuali ditentukan lain dengan -s .
  • Ukuran Filesystem - total kapasitas sistem file (data plus metadata). Diatur secara manual dengan -b switch. Secara default, seluruh volume perangkat blok ditempati.
  • Fitur Incompat - daftar fitur yang disertakan pada btrf yang dibuat yang merusak kompatibilitas dengan versi kernel yang lebih lama. Jika kompatibilitas diperlukan, maka Anda dapat menonaktifkan:

     --features ^extref,^skinny-metadata. 

    Omong-omong, Anda dapat memeriksa fitur apa yang didukung kernel saat ini dengan panggilan berikut:

     mkfs.btrfs --features list-all 
  • Jumlah perangkat dan Perangkat - berapa banyak perangkat blok yang terlibat dalam instance btrfs yang dibuat, dan daftar semua perangkat, masing-masing.
  • Kita juga harus berbicara tentang parameter Profil Grup Blok . Ini menunjukkan profil rekaman yang berlaku untuk masing-masing dari tiga tipe data: Data, Metadata, dan Sistem. Kembali ke struktur umum btrf, kita dapat mengatakan bahwa:

    • Data adalah data pengguna;
    • Metadata adalah kombinasi dari lapisan subvolume dan lapisan metadata dan luasan;
    • Sistem adalah struktur untuk memetakan ruang alamat memori fisik ke ruang terus menerus dari alamat logis.

    Profil rekaman adalah cara menyimpan data di tingkat fisik:

    • Penyimpanan data tunggal dalam satu salinan;
    • DUP - duplikasi data pada satu media;
    • RAIDX adalah salah satu konfigurasi RAID0, RAID1, RAID10, RAID5 dan RAID6.


Saat menandai satu perangkat blok, btrf akan menerapkan duplikasi ke metadata dan data sistem secara default, dan data pengguna akan tetap ada di media dalam satu salinan. Membuat btrf pada beberapa disk sekaligus akan menerapkan profil "RAID0" ke data pengguna secara default, dan "RAID1" ke metadata.
Kelompok parameter ini dikendalikan menggunakan dua kunci: -d untuk data dan -m untuk metadata dan data sistem.

Tapi ada nuansa ... Ada yang berbeda dengan SSD. Faktanya adalah jika kita menandai drive SSD (atau flash drive), maka secara default sistem file tidak akan menduplikasi metadata. SSD dapat memperpanjang deduplikasi data untuk memperpanjang masa pakai elemen memori. Yaitu memiliki dua salinan logis dari data, pada kenyataannya hanya satu yang akan direkam pada media. Akibatnya, ketika segmen memori gagal, "kedua salinan" dari data akan rusak. Selain itu, dengan menulis data dua kali, sumber daya SSD dikonsumsi lebih cepat.

Untuk menentukan jenis media, btrfs memeriksa konten file / sys / block / DEV / antrian / rotasi , di mana "DEV" adalah nama perangkat blok yang sedang diperiksa.
Tentu saja, bahkan dalam kasus SSD, profil penyimpanan dapat dipaksa.

Untuk membuat instance btrfs di beberapa perangkat, cukup tentukan dengan spasi:

 sudo mkfs.btrfs /dev/sdc /dev/sdd -L double_drive 

atau dengan profil:

 sudo mkfs.btrfs /dev/sdc /dev/sdd -d raid1 -m raid1 -L raid1_drive 

Perlu dicatat bahwa media tidak harus memiliki ukuran yang sama, bahkan jika mirroring penuh digunakan. Namun, segera setelah tidak ada cukup ruang pada drive terkecil untuk mengalokasikan memori, sistem file akan menampilkan pesan yang menunjukkan bahwa tidak ada ruang kosong, meskipun secara fisik mungkin masih ada ruang kosong di media lain.

Pemasangan


Mount pertama dari btrf yang baru dibuat tidak berbeda dari sistem file lain:

 mount /dev/sdc /mnt 

Jika sistem file terletak pada beberapa disk, maka untuk pemasangan cukup untuk menentukan salah satu dari mereka.

Secara umum, pemasangan btrf selalu melibatkan pemasangan satu atau lebih dari subvolume-nya. Jika perintah mount tidak ditentukan subvolume mana yang harus dipasang, maka btrfs akan membaca dari catatan khusus ID subvolume, yang harus dipasang secara default. Entri ini nantinya dapat diubah dengan perintah btrfs set-default , tetapi ketika Anda pertama kali memasangnya pada btrfs, hanya ada satu subvolume - root. Ia ditentukan secara default untuk pemasangan.

Root subworld di btrfs selalu ada. Itu muncul bersama dengan sistem file dan tidak mengalami perubahan apa pun di masa depan.

Ada dua cara untuk memasang subvolume selain yang default:
tentukan path dari root subvolume btrfs:

 mount -o subvol=/path/to/subvol /dev/sdc /mnt 

tentukan ID subvolume:

 mount -o subvolid=257 /dev/sdc /mnt 

Seperti yang telah disebutkan, salah satu subvolume btrf ditentukan secara default. Cari tahu mana yang mungkin dengan melakukan:

 btrfs subvolume get-default /path/to/any/subvolume 

Untuk menginstal submount default, Anda dapat menggunakan perintah:

 btrfs subvolume set-default 258 /path/to/any/subvolume 

Path ke subvolume dalam kasus ini diperlukan hanya untuk menunjukkan contoh btrfs spesifik yang digunakan perintah. Omong-omong, ini tidak harus menjadi subworld, jalur ke direktori mana pun juga cocok.

Perintah mount menerima sejumlah besar opsi untuk mengendalikan kapabilitas btrf: defragmentasi, flushing cache, kompresi, cow, logging, balance, dukungan ssd, dan banyak hal lain khusus untuk btrfs. Saya tidak akan mempertimbangkannya dalam kerangka artikel ini, karena mereka diperlukan untuk memperbaiki sistem file, dan dalam sebagian besar kasus Anda dapat melakukannya tanpa mereka.

Subvolume adalah


Subvolume adalah elemen kunci btrf yang melakukan berbagai fungsi:

  • penyimpanan data pengguna dan subvolume lainnya,
  • menyediakan akses ke data (pemasangan),
  • Mekanisme KK
  • membuat snapshot.

Pada perkiraan pertama, subvolume adalah direktori normal. Anda dapat mengganti nama / memindahkannya, melihat isinya, menempatkan dan memodifikasi file di dalamnya. Tidak diperlukan utilitas khusus.

Membuat dan menghapus subvolume dilakukan pada btrf yang terpasang menggunakan perintah khusus:

 btrfs subvolume create /mnt/subvolume_name btrfs subvolume delete /mnt/subvolume_name 

Saya perhatikan bahwa jika Anda mencoba untuk menghapus subvolume menggunakan manajer file atau utilitas rm , operasi akan berakhir dengan operasi yang tidak diizinkan kesalahan (operasi tidak diperbolehkan).

UPD: Dimulai dengan kernel versi 4.18.0, sub-volley dapat dihapus menggunakan utilitas rm atau alat manajer file. Rupanya, itu adalah bug, bukan fitur. Terima kasih kepada Prototik habravchanin untuk klarifikasi.

Setelah membuat subvolume, Anda dapat melihat propertinya:

 btrfs subvolume show /mnt/subvolume_name Name:          subx UUID:          09af45e8-d2b2-b342-8a92-fa270ac82d0a Parent UUID:      - Received UUID:     - Creation time:     2019-03-23 17:59:28 +0100 Subvolume ID:      268 Generation:       39 Gen at creation:    35 Parent ID:       260 Top level ID:      260 Flags:         - Snapshot(s): 

Mari kita mempelajari sifat-sifat utama dari subwolume:

  • Nama - nama subvolume
  • UUID adalah pengidentifikasi unik universal yang berfungsi terutama untuk menentukan hubungan subwoofer-snapshot,
  • Parent UUID - pengidentifikasi leluhur subvolume dari mana leluhur saat ini diturunkan,
  • Menerima UUID - pengidentifikasi leluhur subvolume yang dikirim melalui btrfs send ,
  • Subvolume ID - pengidentifikasi unik untuk penempatan di B-tree,
  • Pembuatan - nomor transaksi pada pembaruan terakhir dari metadata subvolume,
  • Gen at creation - nomor transaksi pada saat subvolume dibuat,
  • ID Induk - pengidentifikasi dari subvolume di mana yang saat ini tertanam,
  • ID tingkat atas persis sama dengan ID Induk,
  • Bendera - bendera (sebenarnya hanya 1 bendera yang dapat dibaca ),
  • Snapshots - daftar snapshot yang diambil dari subvolume ini.

Subvolume memiliki satu parameter lagi - ini adalah path-nya dari btrf elemen root. Path ditampilkan saat mendaftar subvolume:

 btrfs subvolume list /path/to/any/btrfs/mountpoint 

Tapi di sini semuanya sederhana dan jelas - bahkan tidak masuk akal untuk membawa output dari perintah.
Seperti halnya dengan perintah get-default dan set-default , di sini Anda dapat menentukan path ke subvolume apa pun, hasilnya tidak akan berubah. Jalur ini digunakan untuk menemukan root subbolum btrfs. Setelah itu seluruh pohon subwolum dibaca.

Jika Anda mencoba menyalin subvolume, misalnya, dengan utilitas cp , operasi salin akan berhasil, tetapi sebagai hasilnya, bukan subvolume yang akan dibuat, tetapi direktori yang biasa. Namun, btrfs menyediakan alat yang jauh lebih fleksibel untuk membuat salinan seperti itu - snapshot.

Snapshot adalah


Snapshot juga merupakan subworld, hanya memiliki properti tingkat lanjut.

Perbedaan utama mereka adalah bahwa foto itu memiliki catatan dari mana subwolum itu diproduksi. Ini adalah bidang UUID Induk dan Penerimaan UUID . Di subwoofer, bidang ini juga ada, tetapi selalu kosong. Jadi, pada kenyataannya, snapshot dan subvolume adalah satu dan sama.
Saat membuat, Anda dapat memblokir snapshot untuk perubahan menggunakan -r switch.

 btrfs subvolume snapshot -r /path/to/subvol /path/to/snapshot 

Dalam hal ini, file dijamin tetap dalam keadaan di mana mereka dibuat pada saat snapshot dibuat.

Bendera read-only juga dapat dikontrol secara manual, ini berfungsi untuk setiap subvolume:

 btrfs property get /path/to/subvol ro btrfs property set /path/to/subvol ro true 

Jika sekarang kita melihat properti snapshot, kita akan melihat isian UUID Induk yang diisi:

 btrfs subvolume show /path/to/snapshot Name:          subx UUID:          d08612d8-596a-11e9-8647-d663bd873d93 Parent UUID:      09af45e8-d2b2-b342-8a92-fa270ac82d0a Received UUID:     - Creation time:     2019-03-23 17:59:28 +0100 Subvolume ID:      269 Generation:       39 Gen at creation:    35 Parent ID:       260 Top level ID:      260 Flags:         - Snapshot(s): 

Fitur penting dari operasi snapshot adalah ia tidak rekursif. Alih-alih subvolume bersarang, direktori kosong akan dibuat dalam snapshot.

Mari kita beralih ke contoh berikut.

Pada sistem file ada subwoofer "sub0", di dalamnya ada subAwo subAwo dan direktori dirB . Di dalamnya masing-masing adalah fileA dan fileB, masing-masing.

Hapus foto:

 btrfs subvolume snapshot sub0 snap0 



Snap0 snapshot yang dibuat akan mewarisi semua file dan direktori induknya, namun subwoofer subA tidak akan muncul di dalam snapshot. Alih-alih, hanya direktori kosong yang akan muncul dalam snapshot, mis. isi subvolume subA tidak akan diwarisi.

Di satu sisi, ini bagus - kami menghapus snapshot dari subvolume tertentu, dan semua yang bersarang tidak menarik bagi kami. Di sisi lain, jika snapshot rekursif diperlukan, maka btrf tidak memiliki solusi untuk masalah ini. Kita harus mencari putaran pekerjaan.

Solusi pertama didasarkan pada kenyataan bahwa foto itu dihapus tanpa bendera read-only, yang memungkinkan Anda untuk memperbaiki situasi dengan cukup sederhana:

  • hapus direktori tambahan dari snapshot

     rmdir snap0/subA 

  • hapus snapshot dari subvolume bersarang

     btrfs subvolume snapshot sub0/subA snap0/subA 




Jika snapshot dihapus dengan flag read-only, maka opsi di atas tidak akan berfungsi, karena di snap0 Anda tidak dapat menghapus direktori atau menempatkan snapshot. Hanya ada satu opsi - letakkan foto di suatu tempat dekat subwoofer snap0:

 btrfs subvolume snapshot sub0/subA snapA 

dan kemudian pasang snapA di dalam snapshot snap0 , direktori untuk ini sudah ada:

 mount -o subvol=snapA snap0/subA 



Dalam kasus apa pun, penting untuk dipahami bahwa foto rekursif semua akan diambil dalam operasi yang berbeda, pada waktu yang berbeda. Tidak ada pembicaraan tentang penghapusan atom dari snapshot dari beberapa subvolume.

Salin saat menulis


Sedikit tentang pendekatan subvolume dan Kontrak Karya. Bayangkan sebuah subvolume ada pada sistem file dan sebuah file terletak di dalamnya (ambil kasus ideal - file tidak terfragmentasi). Selanjutnya, foto dihapus dari subwolly.



Subvolume baru (snapshot) akan muncul pada sistem file dengan konten yang persis sama dengan subvolume asli. Proses pembuatan snapshot hampir instan - data file itu sendiri tidak disalin. Alih-alih, metadata tambahan dibuat, dan snapshot bersama dengan subvolume induk menjadi pemilik file. Faktanya, hanya ada satu file pada disk, tetapi sekarang file tersebut milik subvolume dan snapshot.
Jika sekarang Anda mengubah file dalam subvolume, maka perubahan tidak akan memengaruhi file dalam snapshot. Jika bendera hanya baca tidak disetel saat membuat snapshot, maka file dalam snapshot juga dapat dimodifikasi.



Secara teknis, ketika file diubah, hanya perubahan ini yang dicatat. Jadi file sumber akan disimpan pada disk plus beberapa delta yang membedakan file asli dari yang dimodifikasi. Jika Anda menghapus salah satu subvolume (yang saya maksud adalah snapshot), maka kelebihan data yang tidak lagi digunakan oleh siapa pun akan terhapus dari disk, dan hanya versi file saat ini yang akan tetap berada di disk (dari sudut pandang subvolume yang tersisa).

Catatan singkat : Setelah dilepaskan, subwoofer akan menghilang dari mata pengguna secara instan, dan utilitas akan mengembalikan kontrol ke terminal, namun, data pada disk akan dibersihkan oleh proses latar belakang untuk beberapa waktu. Artinya, tidak seperti penghapusan direktori biasa, tidak perlu menunggu penyelesaian operasi penghapusan yang sebenarnya. Jika Anda perlu menyinkronkan dengan proses ini dan menunggu sampai selesai, Anda dapat menentukan --commit-after saat memanggil hapus . Perintah daftar subvolume btrfs , dipanggil dengan -d switch, menampilkan daftar subvolume yang telah dihapus oleh pengguna dan saat ini sedang dalam proses dihapus dari disk.

Selain itu, btrfs memungkinkan Anda untuk mengkloning file pada sistem file tanpa menggunakan snapshot. Ini dilakukan dengan menyalin secara teratur dengan --reflink :

 cp -ax --reflink=always /original/file /copied/file 

Kunci reflink=always memberi tahu sistem file bahwa kita ingin menggunakan mekanisme CoW saat menyalin. Setelah menyalin, file dapat diubah secara independen satu sama lain, sehingga kami mendapatkan perilaku yang sama seperti setelah membuat snapshot. Jadi mengapa kita perlu subbolum?

Subtolum pada btrf memainkan peran alat kontrol tingkat tinggi untuk seluruh set data: pertama, itu adalah penghapusan snapshot atom dari semua data subvolume (dalam kasus --reflink atomicity hanya pada tingkat file), dan kedua, dimungkinkan untuk melihat siapa yang diwarisi dari , atau dengan cepat "memutar kembali" data yang disetel ke versi sebelumnya, dll
Dengan demikian, btrf menyediakan kemampuan untuk menangkap status file pada titik waktu yang diinginkan, menggunakan subvolume sebagai sarana tingkat tinggi untuk mengelola status ini.

Pemulihan Subvolume


Dalam bentangan luas, pertanyaan sering muncul: "Saya punya subwoofer, saya punya snapshot, bagaimana cara membalikkan?" Pendekatan ini tidak berlaku untuk btrfs, karena tidak ada kesempatan untuk "memutar kembali subwolly." Sebaliknya, btrfs menawarkan strategi untuk menggantikan subwolly dengan snapshot-nya. Memang, mengapa mengembalikan sesuatu, jika snapshot itu sendiri adalah objek yang ingin kita dapatkan dengan mengembalikan.

Bayangkan skenario ini: pada btrfs ada subvolume di mana file-file database berada (well, atau data penting lainnya). Snapshots secara berkala dihapus dari subvolume ini, dan di beberapa titik ada kebutuhan untuk memutar kembali data. Dalam hal ini, kami cukup menyingkirkan subwolum dan alih-alih mulai menggunakan snapshot yang diambil darinya, atau - jika kami tidak ingin merusak data ini juga - kami menghapus snapshot lain dari snapshot tersebut. Jika subworld asli tidak dipasang dan digunakan sebagai direktori normal, maka itu harus dihapus atau dipindahkan / diganti namanya, dan snapshot harus diletakkan di tempatnya.



Di konsol, mungkin terlihat seperti ini:

  • ganti nama subwolly

     mv the_subvolume the_subvol.old 
  • meletakkan snapshot-nya sebagai pengganti subvolume

     btrfs subvolume snapshot the_snapshot the_subvolume 

Jika subvolume di-mount dan digunakan melalui titik mount, maka itu cukup untuk melepas mount subvolume dan memasang snapshot di tempatnya.



  • Lepaskan subwoofer

     umount /mnt/ 
  • Anda dapat membuat snapshot dari snapshot agar tidak merusak data yang bertahan terakhir:

     btrfs subvolume snapshot /path/to/snapshot /path/to/snapshot_copy 
  • pasang snapshot:

     mount -o subvol=path/to/snapshot_copy /mnt 

Untuk kelengkapan, saya akan coba lagi dan sedikit berbeda. Subvolume tempat perubahan terjadi adalah cabang utama .



Saat membuat snapshot, status file pada disk diperbaiki. Mulai sekarang, foto adalah brunch dari cabang utama . Semua perubahan lebih lanjut ke utama tidak akan memengaruhi snapshot dengan cara apa pun. Kembalikan ke snapshot berarti menghentikan penggunaan cabang utama dan sepenuhnya beralih ke brunch. Cabang utama dapat dihapus jika tidak perlu. Dengan demikian, btrf secara praktis adalah sistem kontrol versi, tetapi tanpa kemampuan untuk menggabungkan cabang kembali.

Pohon sistem file


Salah satu poin tidak jelas yang terkait dengan penggunaan btrfs adalah bagaimana membagi data sistem menjadi subvolume. Tentu saja, tidak ada pendekatan "benar" untuk masalah ini. Tetapi ada 3 cara untuk mengatur struktur subvolume: struktur datar, bersarang dan dicampur.

Struktur datar berarti bahwa subvolume ditempatkan dalam daftar datar di subvolume root. Sebagai contoh, Anda dapat memilih root dari sistem file (sebut saja root ), home direktori pengguna, direktori dengan situs / var / www dan database yang terletak misalnya di / var / database sebagai subvolum terpisah.



Untuk kenyamanan, beberapa subvolume dapat ditempatkan di direktori, seperti, misalnya, dalam kasus subvolume var / www .

Dengan pendekatan ini, semua subvolume harus dipasang. Sub root harus memiliki titik mount /, dan di dalamnya berisi direktori home dan var .Setelah pemasangan akar di / home harus diinstal sabvolyum rumah , dan di / var / www dan / var / databas e - sabvolyumy var / www dan basis data , masing-masing.

Dengan demikian, pohon btrfs-subvolume dapat secara sewenang-wenang ditampilkan dalam sistem file virtual OS, dan sudah ada cukup untuk itu.

Pro:

  • pengguna hanya melihat subvolume yang dipasang,
  • mudah untuk mengganti subwoofer (unmount satu, pasang yang lain),
  • mudah untuk menghapus subwoofer.

Cons:

  • mudah bingung tentang di mana menginstalnya,
  • untuk setiap subvolume harus ada entri di fstab, dan jika ada "kembalikan" ke snapshot, maka entri yang sesuai di fstab juga harus diperbarui.

Struktur bersarang dari subvolume menunjukkan penggunaan sederhana dari subvolume alih-alih beberapa direktori.



Dalam hal ini, selain subvolume root, tidak perlu lagi dipasang.

Pro:

  • semua subvolume terlihat, strukturnya mudah dipahami,
  • Anda tidak perlu memasang apa pun lagi, semuanya seperti dengan sistem file "biasa".

Cons:

  • semua subvolume terlihat, mungkin beberapa ingin bersembunyi dari pengguna,
  • sulit untuk menghapus / mengganti subwolum (alasan untuk ini adalah subwolves bersarang).

Nah, pendekatan ketiga adalah pendekatan campuran. Ini melibatkan kombinasi dari dua yang pertama untuk memaksimalkan manfaat keduanya. Namun, ada kemungkinan bahwa pendekatan khusus ini akan mengarah pada struktur yang rumit, sulit untuk diubah, bingung dengan sejumlah besar entri di fstab. Itu semua tergantung pada ketenangan administrator sistem.



Tambah / hapus disk, keseimbangan


btrfs menawarkan fungsionalitas luar biasa - kemampuan untuk "menambah panas" perangkat secara langsung selama pengoperasian sistem file:

 btrfs device add /path/to/device /path/to/btrfs 

Atau hapus:

 btrfs device remove /path/to/device /path/to/btrfs 

Ngomong-ngomong, dalam satu panggilan tambah / hapus Anda dapat menentukan beberapa disk.
Sekali lagi, path yang ditentukan adalah path ke subvolume dari btrfs dimana perintah akan diterapkan.

Mari kita periksa berapa banyak dan perangkat blok mana yang di bawah kendali btrfs:

 btrfs filesystem show /path/to/btrfs Label: none uuid: 52961dda-df84-4e2d-9727-e93e7738df81       Total devices 2 FS bytes used 192.00KiB       devid  1 size 20.00GiB used 132.00MiB path /dev/sdc       devid  2 size 50.00GiB used 0.00B path /dev/sdd 

0.00B pada bidang yang digunakan memberitahu kita bahwa disk yang ditambahkan kosong. Untuk mengisinya dengan data sesuai dengan profil rekaman, Anda harus menyeimbangkan:

 btrfs balance start /path/to/btrfs 

Perintah balance mendistribusikan ulang data pada disk sesuai dengan profil rekaman yang dipilih. Misalnya, dalam kasus RAID1, keseimbangan akan mengarah pada kloning data dari perangkat asli, dalam kasus RAID0, itu akan menyebabkan distribusi data yang lebih merata di dua disk, dll.
Sebagai hasil dari keseimbangan, jika sebelumnya ada kekosongan pada disk, maka data pada disk tersebut akan ditulis dengan cara yang lebih padat, mis. defragmentasi akan berubah. Namun, penting untuk dipahami bahwa ini bukan defragmentasi "persis". Dalam hal ini, perintah keseimbangan tidak melihat konten logis, tetapi hanya beroperasi pada blok data. Dia tidak memperhatikan fakta bahwa file apa pun tersebar di disk. Sebaliknya, menyeimbangkan transfer blok data dari satu tempat ke tempat lain. Yaitufile yang difragmentasi menjadi seimbang akan tetap terfragmentasi setelahnya. Tapi! Fragmentasi pada tingkat blok data masih akan menurun, dan ini dapat digunakan.

Untuk menghindari kebingungan, katakanlah ini: operasi keseimbangan mengurangi fragmentasi pada tingkat blok data, tetapi tidak memengaruhi fragmentasi file.

Selain itu, perintah keseimbangan menyediakan kemampuan untuk mengubah profil perekaman. Misalnya, profil DUP digunakan pada disk, dan setelah menambahkan disk mereka memutuskan untuk membuat RAID1 penuh. Untuk melakukan ini, gunakan filter convert:

 btrfs balance start -dconvert=raid1 -mconvert=raid1 /path/to/btrfs 

Menggunakan -dconvertdan opsi -mconvert, masing-masing profil catatan baru ditetapkan untuk data dan metadata. Ada juga opsi -sconvert, yang dirancang untuk mengubah profil penulisan data sistem, namun, Anda juga harus menambahkan sakelar -f (--force) untuk memaksa operasi.

Secara umum, tujuan utama filter adalah untuk menetapkan aturan operasi keseimbangan: blok mana yang harus diproses dan mana yang tidak boleh disentuh. Jadi, misalnya, Anda dapat memengaruhi hanya blok yang direkam dengan profil rekaman tertentu (profil filter), atau blok yang ditempati di atas persentase tertentu (filter penggunaan), atau memengaruhi hanya grup blok yang terkait dengan disk tertentu (filter devida), dll. Ngomong-ngomong, mereka masih bisa digabungkan. Secara umum, kemampuan filter sangat luas dan terutama diperlukan untuk melakukan keseimbangan data secara selektif.

Fragmentasi


Sayangnya, btrfs, karena arsitekturnya, sangat rentan terhadap fenomena seperti fragmentasi. Faktanya adalah bahwa data selalu ditulis ke lokasi baru pada disk. Bahkan jika Anda membaca file, tidak melakukan apa-apa dengan data dan menulis kembali ke file yang sama, data akan masuk ke area baru pada disk. Hal yang sama terjadi jika Anda memperbarui data dalam file hanya sebagian - perubahan ditulis ke area baru pada disk. Dengan demikian, perubahan sering file fragmen sangat kuat, meningkatkan "dispersi" fragmen, dalam kasus umum, di beberapa disk. Hal ini menyebabkan peningkatan beban pada CPU dan konsumsi memori yang tidak perlu. Yang paling terfragmentasi adalah database dan gambar mesin virtual.

Anda dapat mengevaluasi fragmentasi file menggunakan utilitas filefrag (tidak termasuk dalam btrfs-progs).

 filefrag /path/to/your/file 

Ini menunjukkan jumlah luasan yang digunakan untuk menyimpan file. Sederhananya - semakin sedikit luasan yang terlibat, semakin sedikit file terfragmentasi.

Ada dua metode untuk memerangi fragmentasi pada btrf: defragmentasi dan flag nocow.

Defragmentasi dapat diterapkan ke satu file atau ke subvolume / direktori, termasuk secara rekursif. Perintahnya adalah sebagai berikut:

 btrfs filesystem defragment /path/to/file/or/dir 

Saya harus mengatakan bahwa tim ini tidak selalu mengarah pada hasil yang diharapkan. File-file kecil, sedikit terfragmentasi (10 - 20 extents) setelah defragmentasi dapat dipecah menjadi lebih banyak bagian. Selain itu, defragmentasi btrf pada beberapa versi kernel memecah deduplikasi file, menjadikannya salinan fisik yang nyata. Yaitufoto-foto di tingkat fisik akan menjadi salinan penuh.

Cara kedua untuk memerangi fragmentasi adalah dengan atribut file nocow.

 chattr +C /path/to/file 

Atribut nocowhanya dapat diatur ke file baru atau kosong. Ini menonaktifkan salinan pada mekanisme tulis , sehingga btrfs akan selalu bekerja dengan area disk tetap saat memperbarui konten file, menulis data dari yang sudah ada (pada tingkat fisik). Dari minus dari nocow - itu juga menonaktifkan memeriksa checksum untuk file ini. Dengan kata lain, tidak ada sapi - tidak ada checksum.

Tentu saja, atur atribut secara manualnocowsetiap file adalah tugas tanpa pamrih. Jika flag dari direktori / subvolume ini diset, maka semua file baru yang dibuat di dalamnya akan mewarisi flag secara otomatis. Hal yang sama berlaku untuk direktori bersarang yang dibuat. Jika pada saat atribut dihidupkan data apa pun sudah ada di direktori, ini tidak akan memengaruhi mereka dengan cara apa pun - atribut nocowhanya dapat diatur ke file baru atau kosong.

Dan cara lain untuk mengatur bendera secara otomatis nocowadalah dengan memasang sistem file dengan opsi nodatacow:

 mount -o subvol=path/to/subvol,nodatacow /dev/sdXX /path/to/mountpoint 

Opsi ini akan menyebabkan opsi terhubung secara otomatis nodatasum, sehingga untuk file yang baru dibuat, checksum tidak akan dihitung.

Seperti biasa, ada nuansa: Anda tidak dapat memasang hanya satu subwoofer dengan opsi nocow. Entah semua subvolume akan memiliki opsi nocow, atau tidak ada. Semuanya diputuskan oleh subvolume pertama yang dipasang: jika memiliki opsi yang ditentukan nodatacow, maka semua pemasangan berikutnya akan berjalan dengan opsi ini secara otomatis.

Momen tidak jelas muncul jika Anda meletakkan bendera pada file nocowdan menghapus snapshot dari subvolume di mana file ini berada. Dalam hal ini, btrf mengabaikan flag nocowjika lebih dari satu subvolume mengacu pada blok data yang diperbarui. Karena itu, meski ada benderanocow(Ngomong-ngomong, file juga akan mewarisi dalam snapshot), perubahan pada salah satu file akan pergi ke area baru pada disk, dan file akan kembali menjadi terfragmentasi. Jika blok data dalam file diperbarui beberapa kali, maka pertama kali itu akan jatuh ke area baru pada disk, dan dengan entri berikutnya akan diperbarui di area baru ini "di tempat".

Trik dan Gagal


Saat menggunakan btrfs-progs, Anda dapat menghilangkan nama lengkap dari perintah:

 btrfs sub cre = btrfs subvolume create 

Cukup hanya kebetulan karakter pertama, yang secara unik menentukan perintah:

 su = subvolume, fi = filesystem, ba = balance, de = device; 

Saya pikir prinsipnya jelas.

Sayangnya, btrfs tidak dapat membuat snapshot dari direktori, tetapi ada solusinya:

  • buat subvolume

     btrfs subvolume create ./subvol 
  • salin file dari direktori ke subvolume:

     cp -ax --reflink=always your/dir/. ./subvol 

    kuncinya reflink=alwaysakan menggunakan mekanisme Kontrak Karya, mis. data tidak akan disalin, tetapi tautan ke sana akan dibuat pada btrf tingkat rendah.
  • Sekarang subworld berisi semua file yang ada di direktori, dan Anda dapat menghapus snapshot darinya.

Anda nocowtidak dapat mengatur atribut ke file data yang ada. Namun, Anda dapat pergi dengan cara berikut:

  • buat file kosong

     touch nocowfile 
  • beri dia bendera nocow
  • mengalokasikan ruang disk untuk file baru

     fallocate -l10g nocowfile 
  • salin konten file yang ada ke

     cp -v oldcowfile nocowfile 

Jika btrf kehabisan ruang, bahkan menghapus file dapat menyebabkan kesalahan โ€œTidak ada ruang tersisa di perangkatโ€ . Untuk solusinya, disarankan untuk menghubungkan drive sementara dengan ukuran sebaiknya minimal 1GB ke btrfs. Lalu bersihkan datanya. Kemudian lepaskan drive sementara.

Operasi keseimbangan , dijalankan tanpa menentukan profil tulis, secara implisit mengubahnya dari dup ke raid1 . Apa, yang kebetulan, tertulis di halaman Gotchas . Ini terjadi setelah menambahkan disk ke btrfs, yang menggunakan profil tulis dup . Ingatlah bahwa memformat satu drive dalam btrfs menggunakan profil dup default untuk metadata dan data sistem.

Mungkin yang paling penting


Hindari membuat klon perangkat blok tingkat rendah dengan btrfs. Menjadi sistem file "pintar", untuk beberapa operasi (paling sering, ketika pemasangan) btrf membaca kembali data sistem pada perangkat blok untuk menemukan semua bagian dari sistem file. Jika dua perangkat blok dengan UUID yang sama ditemukan dalam proses pencarian, maka btrf akan menerimanya sebagai bagian dari instance yang sama. Jika pada saat yang sama kedua perangkat ini ternyata asli dan tiruannya, maka setelah menginstal driver sendiri tahu bagaimana sistem file akan bekerja, tetapi jelas bahwa ini tidak akan berakhir dengan sesuatu yang baik. Dalam kasus terburuk, itu akan menghasilkan korupsi data yang tidak dapat dipulihkan.

Jika Anda benar-benar ingin mengkloning disk dengan btrfs dengan cara tingkat rendah, Anda harus sangat berhati-hati. Secara umum, klon tidak boleh terlihat oleh kernel OS sebagai perangkat blok sementara yang asli hadir dalam sistem, dan sebaliknya. Dengan ketentuan ini, Anda dapat mengubah UUID klon (baik, atau asli, di sini opsional). Utilitas btrfstune yang datang dengan paket btrfs-progs akan membantu :

 btrfstune -u /path/to/device 

Dan lagi: btrfstune , menjadi utilitas "pintar", akan mengubah UUID tidak hanya pada disk, tetapi pada seluruh sistem file. Ini berarti bahwa ketika dipanggil, ia akan membaca semua perangkat blok untuk mengganti UUID pada semua perangkat yang terkait dengan sistem file.

Alih-alih sebuah kesimpulan


Jika saat ini Anda tidak mengerti apa-apa - ini normal. Btrfs nontrivial dan mungkin tidak segera menyerah. Setiap kali saya merasa bahwa sekarang saya memahaminya, dia membuat kejutan dan membuatnya memikirkan hal-hal yang ada. Saya tidak bisa mengatakan bahwa saya mengerti segalanya pada saat ini - dalam proses penulisan saya menemukan sesuatu yang baru, walaupun saya sudah menulis berdasarkan pengalaman saya.

Saya akan membandingkan proses penguasaan btrf dengan transisi dari gaya pemrograman prosedural ke yang berorientasi objek. Kesan pertama adalah "wow, betapa mengagumkan", tetapi kemudian Anda terus menulis kode prosedural yang dibungkus dalam kelas.

Dalam artikel itu, saya berusaha untuk tidak menuangkan air - untuk menulis segala sesuatu tentang kasus ini. Meskipun demikian, ini ternyata cukup banyak. Tetapi jauh dari segalanya adalah mungkin untuk diceritakan - Anda masih dapat menulis dan menulis tentang btrfs. Artikel ini hanyalah puncak gunung es. Awal mulanya adalah memahami filosofi dan mulai menggunakannya. Dan sekarang saatnya untuk mengakhiri.

Terima kasih sudah membaca sampai akhir. Saya harap tidak lelah. Tuliskan di komentar tentang apa lagi yang Anda tertarik untuk tahu.

Buat cadangan, tuan-tuan. Dan biarkan mereka tidak pernah berguna.

Source: https://habr.com/ru/post/id458250/


All Articles