ZFS: Bagaimana Anda mengembalikan jumlah salinan yang benar setelah kehilangan drive?


12

Dengan zfs, jika Anda memiliki copies=2dan kemudian Anda kehilangan drive yang berisi beberapa salinan itu, bagaimana Anda memberi tahu sistem bahwa ia harus membuat salinan baru dari blok data untuk file yang terpengaruh? Atau apakah zfs mulai menambahkan blok data untuk salinan tambahan segera setelah mengetahui tentang blok data yang buruk?

Akankah scrub melakukan ini?

(v0.6.0.56-rc8, ZFS pool versi 28, ZFS filesystem versi 5, Ubuntu 11.10)

Jawaban:


10

"salinan = 2" (atau 3) lebih dirancang untuk digunakan dengan kumpulan tanpa redundansi (disk tunggal atau strip). Tujuannya adalah untuk dapat memulihkan kerusakan disk kecil, bukan kegagalan seluruh perangkat. Dalam kasus terakhir, pool tidak dapat di-mount sehingga restorasi blok tidak dapat terjadi.

Jika Anda memiliki redundansi (mirroring / raidz / raidz2 / raidz3), blok ditto tidak berbeda dari yang lain dan scrubbing / resilver akan membuatnya kembali.


Ini secara langsung bertentangan dengan apa yang dikatakan @Redmumba - dan Redmumba menyediakan tautan ke kode. Bisakah Anda mengutip beberapa sumber untuk apa yang Anda katakan? Secara khusus, saya ingin melihat kutipan yang bagus untuk mengapa Anda berpikir salinan = N tidak akan mengatasi kegagalan seluruh perangkat - itu tidak cocok dengan apa pun yang saya baca.
James Moore

1
@ James Moore Setelah kegagalan seluruh perangkat, tidak ada blok ditto akan ditulis pada disk itu. Tidak ada redundansi di level pool sehingga tidak ada cara untuk mengganti disk yang rusak dengan yang baru. Satu-satunya metode untuk memulihkan situasi dengan benar adalah melakukan pencadangan penuh kumpulan, membuatnya kembali dengan perangkat yang sehat, dan memulihkan dari cadangan sambil memastikan tidak ada reboot yang tidak disengaja terjadi sebelum pencadangan pertama dilakukan. Kalau tidak, kumpulan mungkin tidak dapat diimpor dan datanya hilang. Ini adalah beban yang cukup dibandingkan dengan kolam yang redundan di mana memulihkan disk buruk dilakukan secara online dan selamat dari reboot.
jlliagre

1
Berikut ini adalah referensi: docs.oracle.com/cd/E19082-01/817-2271/gbbvf/... For a device to be replaced, the pool must be in the ONLINE state. The device must be part of a redundant configuration, or it must be healthy (in the ONLINE state). Saya menganggap salinan = 2 atau 3 tidak dianggap sebagai konfigurasi yang berlebihan.
jlliagre

1
Satu hal yang perlu diingat, adalah bahwa jika Anda awalnya copies=1dan Anda telah menaikkannya copies=2, maka Anda mungkin ingin resilver / rescrub sesudahnya - yang akan membuat instance ini. Tapi @ jilliagre benar: blok ditto bukan merupakan konfigurasi yang berlebihan. Tidak ada jaminan bahwa blok ditetapkan pada perangkat lain, bahkan jika Anda memiliki beberapa perangkat dalam kumpulan.
Andrew M.

1
fitur "salinan = N di mana N> 1" tidak dimaksudkan untuk menambah redundansi. ini dimaksudkan untuk menyelesaikan korupsi data. segala sesuatu yang dituliskan ke zfs adalah checksummed atau hash. ketika dibaca kembali, checksum / hash diverifikasi. jika N = 1, maka kegagalan verifikasi checksum / hash menghasilkan kesalahan kembali ke aplikasi. jika N> 1, maka salah satu salinan lainnya dapat dikonsultasikan dan digunakan untuk memperbaiki semua salinan lainnya.
longneck

9

Saya menemukan pertanyaan ini sangat menarik, dan setelah menghabiskan satu jam menuangkan dokumentasi, saya menyelam ke dalam kode. Inilah yang saya temukan.

Pertama, beberapa terminologi. Blok Ditto (yang merupakan salinan-salinan ini, sebagai lawan dari mirror) secara otomatis dibuat pada penulisan tetapi mungkin atau mungkin tidak pada perangkat virtual yang sama (vdev) seperti salinan aslinya. Di sisi lain, blok cermin selalu tercermin ke perangkat virtual lain.

Namun, kode mengacu pada kedua jenis blok sebagai anak-anak. Anda akan melihat di sini bahwa blok hanya anak-anak dengan io_vd == NULLini (ini ada dalam fungsi tulis). Untuk blok cermin, io_vdakan diatur ke perangkat virtual yang sesuai (disk kedua Anda, misalnya).

Dengan mengingat hal itu, ketika sampai ke bagian baca , itu memperlakukan semua anak (apakah mereka mencerminkan atau memblokir blok) sebagai berpotensi tidak aman jika tidak mengandung yang diharapkan good_copies, dan menulis ulang mereka sesuai kebutuhan . Jadi sepertinya jawaban untuk pertanyaan Anda adalah - ya, itu akan menulis ulang ketika Anda memiliki setidaknya satu salinan yang baik, dan salah satu dari yang berikut:

  • Kesalahan tak terduga saat Anda mencoba membaca data,
  • Anda sedang resilver, atau
  • Anda sedang menggosok.

Fiuh! Mungkin seseorang dapat menunjukkan kekurangannya, tapi saya senang belajar tentang ZFS melalui latihan kecil ini, dan saya harap ini membantu!


1
Masalahnya ada pada jawaban @ jlliagre - pool sudah mati jika kehilangan perangkat apa pun. Kenyataan bahwa kolam masih memiliki cukup banyak blok tampaknya tidak masalah. Ada jalan lain?
James Moore

4
@JamesMoore Anda dapat memaksa array online dalam kondisi terdegradasi jika Anda memiliki 1MB perangkat pertama yang gagal. Agaknya Anda hanya perlu metadata dari perangkat yang gagal. Saya telah menguji ini dengan zpool gaya-jbod dan berfungsi: memulihkan label yang rusak raidz . Saya melakukan md5sum sebelum dan sesudah saya memecahkan zpool, dan hanya sistem file copy = 1 yang rusak setelah impor. Salinan = 2 dan salinan = 3 sistem file cocok dengan sempurna.
Jodie C

2

@ jlliagre dan lainnya yang tampaknya berpikir bahwa seluruh zpool akan mati jika salah satu disk (vdevs) mati tetapi kolam tidak berlebihan (mirror / raidz). Ini tidak benar; kolam multi-disk akan selalu bertahan kegagalan disk tunggal lengkap bahkan jika itu bukan cermin atau raidz.

ZFS Metadata selalu disalin setidaknya 2 kali sehingga total kegagalan dari disk lengkap (atau bagian dari itu) tidak akan menghapus sistem file. Selain itu, banyak file, terutama yang lebih kecil, tidak akan tersebar di semua disk dan karena itu tidak perlu disalahkan oleh kegagalan disk. OP bertanya tentang kasus kumpulan multi-disk menggunakan blok ditto (salinan data pengguna> 1). Di sini, kegagalan disk tunggal lengkap harus tidak pernah menghasilkan hilangnya data.ZFS akan selalu mencoba untuk menempatkan blok-blok jauh jauh dari blok asli, dan untuk kumpulan dengan banyak vdev, ini selalu berarti pada vdev lain (pengecualian mungkin di mana satu vdev> 50% dari kumpulan, yang akan sangat tidak biasa) . Meta data sistem file juga selalu disalin +1 atau +2 kali lebih banyak dari level ditto , sehingga akan selalu selamat dari kegagalan disk. Selain itu, jika Anda memiliki kumpulan lebih dari tiga disk, Anda harus dapat kehilangan hingga setengahnya tanpa kehilangan data; ZFS menyimpan blok-blok ditto pada disk berikutnya agar selama Anda tidak pernah kehilangan dua disk yang berdekatan, Anda tidak akan pernah kehilangan data. (tiga kegagalan disk tambahan untuk ditto = 2).

Ketika ada salinan data yang cukup untuk mengakses file (apakah salinan itu dari blok ditto, mirror, atau raidz), maka semua salinan data yang hilang diperbaiki ketika file diakses. Ini adalah tujuan dari scrub; baca semua data dan perbaiki yang salah dengan memanfaatkan salinan yang berlebihan. Jadi untuk menjawab pertanyaan OP secara langsung, Anda hanya perlu melakukan scrub setelah mengganti drive yang gagal, dan semua salinan akan dikembalikan.

Seperti biasa, Anda dapat dengan mudah bereksperimen dengan konsep-konsep dengan membuat kumpulan yang vdev-nya untuk mendukung penyimpanan hanya file jarang. Dengan menghapus atau merusak file vdev Anda dapat mensimulasikan segala jenis kegagalan, dan dapat memverifikasi integritas kumpulan, sistem file, dan data di sepanjang jalan.

EDIT: setelah bereksperimen, sepertinya zfs akan gagal pool jika disk gagal dalam multi-disk non-redundant pool dengan salinan> = 2. Korupsi data parital pada satu disk atau lebih harus tetap bertahan dan harus diperbaiki oleh scrub.


Yang menakutkan tentang eksperimen semacam itu adalah mereka bagus untuk memberi tahu saya bahwa pengaturan akan gagal segera atau setidaknya dengan cepat. Mereka tidak begitu hebat untuk mengatakan kepada saya bahwa setup akan gagal sesekali. Bagaimanapun, tidak jelas bagaimana Anda mengembalikan kolam yang mengalami kegagalan; Saya mencoba menyiapkan kumpulan seperti ini dengan tiga file jarang dan menghapus salah satu file jarang tampaknya berakibat fatal bagi seluruh kumpulan. Ganti zpool tidak akan mengganti file yang gagal, kios scrub zpool di 5% (dan ini adalah kolam yang sangat kecil), dan halaman kesalahan di illumos.org/msg/ZFS-8000-5E tidak optimis.
James Moore

Saya memiliki hasil yang mirip dengan pengalaman saya, dilakukan hanya setelah jawaban saya. Saya biasanya hanya menggunakan raidz, dan menjawab berdasarkan informasi dari apa yang saya yakini sebagai sumber yang kredibel (blog oracle). Saya tidak lagi percaya bahwa kumpulan tipe multi-disk JBOD, dengan salinan> 1 dapat bertahan dari kegagalan disk.
Aaron B
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.