Alasan di balik hosting gambar disk virtual di BTRFS Filesystem


14

Saya telah membaca tentang BTRFS dan ZFS untuk sementara waktu dan sementara saya sangat menghargai manfaat dari Kontrak Karya ketika hosting file penting saya saat ini bingung dengan dilema berikut:

Mengingat bahwa baik ZFS dan BTRFS tampaknya mengalami penurunan kinerja ketika hosting file besar tunduk pada penulisan acak (misalnya QCOW2, VDI, dll), mengapa seseorang menggunakan BTRFS sebagai FS pilihan untuk meng-host VM?

Saya tahu bahwa dalam kasus BTRFS Anda dapat mematikan SAP secara selektif menggunakan chattr, atau opsi mount nodatacow, mengurangi degradasi yang ditimbulkan oleh fragmentasi dan KK ...

Namun, menurut Redhat ini juga "menonaktifkan verifikasi checksum data dan metadata, sehingga integritas data berkurang." (selain kompresi yang hilang dan tentu saja Kontrak Karya yang diinginkan).

Berdasarkan itu saya bertanya: Mengapa seseorang memilih BTRFS lebih dari katakanlah, XFS lebih dari LVM lebih dari MD RAID?


Perhatikan bahwa integritas data yang berkurang akan sama dengan menggunakan sebagian besar sistem file lain seperti ext4 atau xfs yang sama sekali tidak menyimpan checksum dan karenanya tidak dapat mendeteksi korupsi.
basic6

1
@ basic6 Saya sadar. Karena itu pertanyaannya.
Andre de Miranda

Jawaban:


13

Jika use case utama adalah menyimpan gambar atau database VM, dan Anda tidak tertarik menerima potensi masalah kinerja untuk mendapatkan keunggulan integritas data btrfs, maka saya tidak bisa memikirkan alasan mengapa Anda ingin memilih btrfs lebih dari xfs atau ext4.

Menonaktifkan copy-on-write hanya untuk direktori gambar VM (menggunakan chattr + C) sebagian besar relevan ketika menyimpan gambar VM hanya salah satu dari banyak kegunaan yang Anda miliki untuk sistem file Anda. Maka bisa sangat mudah untuk menonaktifkan copy-on-write untuk direktori tunggal itu, namun tetap mempertahankan semua kelebihan btrfs untuk sisa sistem file.


Alasannya adalah memiliki disk tanpa tabel partisi. BTRFS memungkinkan grub / etc untuk disematkan langsung ke dalamnya, XFS / EXT4 / etc tidak .. Saya sudah mencari sistem file yang memungkinkannya sebagai BTRFS's CoW di atas BTRFS yang saya gunakan untuk menyimpan VM gambar tidak ideal (saya menggunakan snapshots dan btrfs-RAID10 pada host), dan chattr + C tampaknya menjadi satu-satunya pilihan saya di luar menggunakan tabel partisi. Kira saya hanya akan menggunakan tabel partisi.
Alex

5

BTRFS memiliki format disk yang berbeda yang akan mengungguli sistem file lain pada beberapa pola tulis. Secara khusus sejumlah besar upaya telah dihabiskan dalam meningkatkan bagaimana meta-data ditulis ke disk dan mendukung beberapa fitur canggih seperti pemeriksaan data, kompresi, dan snapshot. Untuk file besar meningkatkan kinerja meta-data umumnya tidak penting.

Dibandingkan dengan ZFS, BTRFS adalah solusi yang lebih sederhana dan lebih baik didukung di Linux. Kelemahan utama adalah bahwa ia tidak skala juga (ketika menambahkan sejumlah besar disk) dan tidak memiliki set fitur yang sama.

Dibandingkan dengan XFS, ini akan menjadi solusi kinerja yang lebih rendah. Yaitu akan membutuhkan lebih banyak waktu prosesor untuk menulis sepotong data ke disk dan akan dibatasi dalam throughput maksimum. Ini dapat dikurangi sampai batas tertentu dengan melakukan hal-hal seperti menonaktifkan verifikasi checksum, tetapi kemudian Anda kehilangan manfaat utama BTRFS dibandingkan XFS yang meningkatkan informasi meta-data. Yaitu checksumming dan jurnal yang berbeda (yang mungkin lebih baik dalam beberapa situasi).

Dalam hal dukungan Copy On Write (COW), XFS lebih menyukai kinerja daripada menjadi SAP. Yaitu XFS memiliki meta data yang sangat baik dan fitur penjurnalan dalam hal skalabilitas dan umumnya tidak akan menimpa data file pada penulisan dengan pengecualian bahwa itu akan memungkinkan blok disk yang ada untuk over-tertulis jika aplikasi secara khusus meminta untuk menulis data itu secara berlebihan. . Ini bisa baik dalam kasus VM karena alokasi disk Anda pada awalnya bisa bersebelahan dan dalam kasus itu akan tetap bersebelahan untuk masa pakai VM.


5

Menggunakan BTRFS, bahkan dengan nodatacowdan serupa Anda masih dapat membuat snapshot data secara manual dengan CoWperilaku, sehingga cepat dan tidak menghabiskan banyak memori. Selain itu, snapshot tersebut lebih fleksibel daripada menggunakan LVM, karena Anda tidak perlu memesan ruang di bawah sistem file yang tidak disadari oleh sistem file dan tidak dapat digunakan jika tidak diperlukan sama sekali. Seperti halnya ZFS, snapshot dapat dikirim dan diterima melalui jaringan, yang mungkin membantu Anda meningkatkan strategi cadangan Anda. Jadi bahkan dengan nodatacowBTRFS tampaknya lebih unggul daripada menggunakan LVM.


3

Setelah bekerja dengan platform komputasi awan saya datang untuk mengadopsi pandangan mereka tentang mesin virtual sebagai wadah untuk data dan fungsionalitas di mana vm sebenarnya kurang penting.

Saya lebih suka memiliki proses backup-restore dan install-deploy yang baik dan lebih sedikit khawatir tentang integritas VM dan lebih banyak tentang kinerja.

Yaitu pergi untuk JFS / XFS / EXT4 melalui LVM lebih dari MD-raid daripada BTRFS. Pastikan saya tidak pernah menyimpan apa pun yang tidak didukung pada VM untuk jangka waktu yang lebih lama ... dan memiliki skrip dan prosedur untuk mendapatkan instalasi baru cadangan VM dalam waktu yang wajar jika terjadi sesuatu.

Tapi ini lebih dari skenario dev / eksperimen daripada yang lain.

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.