ZFS'de güncelleme sağlama toplamı zorunlu mu?

Geçenlerde değişti checksumbenim olmayan çoğaltılmış zfs dosya sistemlerinin birinde özelliğini sha256dan ondaha iyi bu komutla olduğu gibi yinelenen çoğaltma buharlarının göndermeyi desteklemek için (Fletcher4) zfs send -DR -I _starting-snaphot_ _ending-snapshot_.

Ancak, zfs manpage'in şunları söylemesi gerekir send -D:

Bu bayrak, veri kümesinin tekilleştirme özelliğinden bağımsız olarak kullanılabilir, ancak dosya sistemi tekilleştirme özelliğine sahip bir sağlama toplamı (örneğin, sha256) kullanıyorsa performans çok daha iyi olacaktır.

Zfs manpage ayrıca bu checksumözellik hakkında şunları belirtir :

Bu özelliğin değiştirilmesi yalnızca yeni yazılmış verileri etkiler.

Fletcher4'e güvenme arzum yok. İstisna şudur: SHA256'dan farklı olarak, fletcher4 sahte bir karma fonksiyonu değildir ve bu nedenle çarpışmamalarına güvenilemez. Bu nedenle, yalnızca karma çarpışmalarını algılayan ve çözen 'doğrulama' seçeneğiyle birleştirildiğinde tekilleştirme için uygundur.

Dosya sisteminin sağlama toplamlarını, tercihen sistemi devre dışı bırakmadan nasıl güncelleyebilirim?

zfs zfsonlinux

— 84104
kaynak

Zaten yazılmış verilerin özelliklerini (sıkıştırma, veri tekilleştirme veya sağlama toplamı) değiştirmek için, zfs yaklaşımı verileri bir zfs send | zfs receivesekans üzerinden çalıştırmaktır . Açıkçası, bunun için sistemi çevrimdışına almanıza gerek yok, ancak ihtiyacınız olacak

zpool'unuzda / sisteminizde söz konusu veri kümesinin yinelenen yinelenen kopyalarını alacak kadar kaynak
Veri kümesinin yok edilmesi veya prosedürde yeniden adlandırılması gerektiği için kesinti süresi
operasyonun tamamlanması için yeterli zaman ve sabır

Zpool için yinelenenleri kaldırma işlemini kullandığınız için, hedefle zfs send | zfs receivekaynakla aynı havuzda çalışmak yalnızca yeni yazılan meta veri blokları için gereken alanı kullanır. Ancak kopyanın bir süre alması için hazırlıklı olun - özellikle de tüm yinelenenleri kaldırma tablosunu RAM'de tutmak için yeterli RAM'iniz yoksa, yinelenenleri kaldırma işlemi çok yavaş olabilir.

Veri kümesinin son, yetkili bir kopyasını oluşturmak için tüm yazma işlemlerini kesinlikle durdurmanız gerekir, ancak önce bir anlık görüntüyü kopyalayarak, tüm yazmaları durdurarak zfs send -i | zfs receiveve son adım olarak artımlı yaparak kesinti süresini en aza indirebilirsiniz .

— -tavşansın
kaynak

zfs receiveBir dosya sisteminin meta verilerini güncelleyen benim için net değil . Bana öyle geliyor ki, meta verileri olduğu gibi almanın çok daha hızlı olacağını düşünüyorum. Bununla birlikte, dosya düzeyi düzey doğası yerine sağlama toplamının bloğu nedeniyle bunu yapmak imkansız olabilir. Bu durumda zfs send | zfs receivebir çözüm için kabul edilebilir bir baz oluşturur.

— 84104

zfs gönder | zfs recv tüm meta verileri etkin bir şekilde değiştirir (sıkıştırma seçimi, sağlama toplamı seçimi, veri tekilleştirme seçimi). zfs send, zfs recv kullanarak aldığınız bir nesneyi oluşturuyor ve bu da sanki tamamen yeni verilermiş gibi yazıyor. Ancak - Ben tekilleştirme ile ilgili olarak zfs send | recv hakkında bir yanlış anlama altında olabilir düşünüyorum. zfs -D, verilerin kaynak veri kümesinden var olan veri tekilleştirmesini sürdürmeyen verileri / akışın kendisinde / tekilleştirmeye çalışır. Bu nedenle recv tarafının hedef veri kümesinde yinelenenleri kaldırma özelliğinin etkinleştirilmiş olmasına gerek yoktur.

— Nex7

Daha fazla açıklamak gerekirse - zfs | recv tekilleştirilmemiş verilerini tel üzerinden geçen her şeyin tekilleştirilmiş verilerin ve ilişkili tekilleştirme tablosu girişlerinin tek bir kopyası olacak şekilde göndermesinin bir yolu yoktur. Kaynak ve hedef senkronize olsa ve artımlı bir anlık görüntüden başka bir şey göndermiyor olsanız bile. ZFS, içindeki verilerin veri tekilleştirilemez olması / akışın kendisi kapsamında olması durumunda gönderme verilerini tam boyuta kadar balonlar. POOL DDT'de kolayca tekilleştirilen verileriniz olabilir, ancak küçük bir gönderme nesnesi olarak tümüyle tekilleştirilemez olun.

— Nex7