Dla was wszystkich ... ZFS nad każdym RAIDem jest całkowitym BÓLEM i jest wykonywany tylko przez ludzi MAD! ... jak używanie ZFS bez pamięci ECC.
Dzięki próbkom zrozumiesz lepiej:
- ZFS przez Raid1, jeden dysk został nieco zmieniony, gdy nie był wyłączony ... podważ wszystko, co wiesz, ZFS zobaczy pewne uszkodzenia lub nie w zależności od tego, który dysk zostanie odczytany (kontroler RAID nie widział tego bitu zmienionego i myśli, że oba dyski są OK ) ... jeśli błąd znajduje się w części VDEV ... cały ZPOOL na zawsze traci wszystkie swoje dane.
- ZFS przez Raid0, jeden dysk został nieco zmieniony, gdy nie był wyłączony ... podważ wszystko, co wiesz (kontroler RAID nie widział tego bitu zmienionego i myśli, że oba dyski są w porządku) ... ZFS zobaczy takie uszkodzenie, ale jeśli fail jest w części VDEV ... cała ZPOOL na zawsze traci wszystkie swoje dane.
ZFS jest dobry w wykrywaniu bitów, które zmieniły się, gdy dysk nie ma zasilania (kontrolery RAID nie mogą tego zrobić), a także gdy coś się zmieni bez poproszenia itp.
Jest to ten sam problem, co w przypadku, gdy nieco w module pamięci RAM zmienia się spontanicznie, bez pytania o ... jeśli pamięć to ECC, pamięć samodzielnie ją koryguje; jeśli nie, dane się zmieniły, więc dane zostaną przesłane na zmodyfikowane dyski; módlcie się, że zmiana nie dotyczy części UDEV, jeśli błąd występuje w części VDEV ... cała ZPOOL na zawsze traci wszystkie swoje dane.
Jest to słabość ZFS ... Awarie VDEV oznaczają, że wszystkie dane zostaną utracone na zawsze.
Hardware Raid i Software Raid nie mogą wykryć spontanicznych zmian bitów, nie mają sum kontrolnych, najgorsze na poziomach Raid1 (mirros), czytają nie wszystkie części i porównują je, zakładają, że wszystkie części zawsze będą miały te same dane, ZAWSZE (mówię głośno) Raid zakłada, że dane nie zmieniły się w żaden inny sposób / w inny sposób ... ale dyski (jako pamięć) są podatne na spontaniczne zmiany bitów.
Nigdy nie używaj ZFS na RAMie innym niż ECC i nigdy nie używaj ZFS na napadanych dyskach, pozwól ZFS zobaczyć wszystkie dyski, nie dodawaj warstwy, która może zrujnować VDEV i POOL.
Jak zasymulować taką awarię ... wyłącz komputer, wyjmij jeden dysk tego Raid1 i zmień tylko jeden bit ... powtórz i zobacz, jak kontroler Raid nie wie, że to się zmieniło ... ZFS może, ponieważ wszystkie odczyty są testowane z sumą kontrolną i jeśli nie pasuje, czytaj z innej części ... Raid nigdy nie czyta ponownie, ponieważ błąd (z wyjątkiem niemożliwego odczytu sprzętu niemożliwy) ... jeśli Raid może odczytać, myśli, że dane są w porządku (ale nie w takich przypadkach ) ... Raid próbuje tylko czytać z innego dysku, jeśli w miejscu, w którym się odczytuje, mówi „hej, nie mogę stamtąd czytać, awaria sprzętu” ... ZFS odczytuje z innego dysku, jeśli suma kontrolna nie jest taka sama, jak w przypadku, gdy to czyta mówi „hej, nie mogę stamtąd czytać, awaria sprzętu”.
Mam nadzieję, że pozwolę to bardzo jasno wyjaśnić ... ZFS na dowolnym poziomie Raidu to ból toalet i całkowite ryzyko dla twoich danych! a także ZFS w pamięciach innych niż ECC.
Ale nikt nie mówi (oprócz mnie):
- Nie używaj dysków z wewnętrzną pamięcią podręczną (nie tylko SHDD, także niektóre z pamięcią podręczną od 8 Mb do 32 MB itp.) ... niektóre z nich używają pamięci innej niż ECC do takiej pamięci podręcznej
- Nie używaj SATA NCQ (sposób na zapisywanie w kolejce), ponieważ może zniszczyć ZFS w przypadku utraty zasilania
Jakich dysków użyć?
- Każdy dysk z wewnętrzną baterią, który zapewnia, że cała kolejka zostanie zapisana na dysku w przypadku awarii zasilania i wykorzystuje w nim pamięć ECC (przepraszam, jest ich bardzo mało i są drogie).
Ale, hej, większość ludzi nie wie o tym wszystkim i nigdy nie miała problemu ... mówię im: wow, jakie masz szczęście, kup jakieś losy, zanim szczęście zniknie.
Istnieje ryzyko ... takie awarie mogą się zdarzyć ... więc lepszą odpowiedzią jest:
- Staraj się nie umieszczać żadnej warstwy między ZFS a miejscem, w którym dane są naprawdę przechowywane (RAM, Raid, NCQ, wewnętrzna pamięć podręczna dysku itp.) ... tyle, na ile możesz sobie pozwolić.
Co ja osobiście robię?
- Dodaj jeszcze kilka warstw ... używam każdego dysku 2,5 "SATA III 7200 obr./min na obudowie USB 3.1 Gen2 typu C, podłączam niektóre obudowy do koncentratora USB 3.1 Gen 2 typu A, który podłączam do komputera; inne do innego koncentratora że podłączam się do innego portu głównego komputera PC itp.
- W systemie używam wewnętrznych łączników SATA na ZFS (poziom Raid0), ponieważ używam niewymienialnego (jak LiveCD) systemu Linux, każdy rozruch identycznej zawartości na dyskach wewnętrznych ... i mam obraz Clone systemu, który mogę przywrócić (mniej niż system 1GiB) ... również używam sztuczki, aby system znajdował się w pliku i używam dysku zamapowanego w pamięci RAM, gdzie klonowałem go podczas rozruchu, więc po uruchomieniu cały system działa w pamięci RAM ... umieszczając taki plik DVD mogę również uruchomić w ten sam sposób, więc w przypadku awarii dysków wewnętrznych po prostu uruchamiam się z DVD, a system jest ponownie w trybie online ... podobna sztuczka do SystemRescueCD, ale trochę bardziej złożony plik ISO może być na wewnętrzny ZFS lub po prostu prawdziwy DVD i nie chcę dwóch różnych wersji.
Mam nadzieję, że mógłbym rzucić nieco światła na ZFS przeciwko Raidowi, to naprawdę jest ból, gdy coś pójdzie nie tak!