Bezpieczeństwo pamięci podręcznej zapisu na dyskach SATA z barierami

13

Czytałem ostatnio o buforowaniu zapisu, NCQ, błędach oprogramowania, barierach itp. Dotyczących napędów SATA i nie jestem pewien, jakie jest najlepsze ustawienie, które zapewniłoby bezpieczeństwo moich danych w przypadku awarii zasilania.

Z tego, co rozumiem, NCQ pozwala napędowi na zmianę kolejności zapisów w celu zoptymalizowania wydajności, przy jednoczesnym informowaniu jądra o tym, które żądania zostały fizycznie zapisane.

Pamięć podręczna zapisu powoduje, że dysk obsługuje żądanie znacznie szybciej, ponieważ nie czeka na zapisanie danych na dysku fizycznym.

Nie jestem pewien, jak mieszają się tutaj pamięć podręczna NCQ i Write ...

Systemy plików, zwłaszcza rejestrowane w dziennikach, muszą mieć pewność, kiedy określone żądanie zostało zapisane. Ponadto proces przestrzeni użytkownika używa fsync () do wymuszenia opróżnienia określonego pliku. To wywołanie fsync () nie powinno wrócić, dopóki system plików nie upewni się, że dane są zapisane na dysku.

Istnieje funkcja (FUA, Force Unit Access), którą widziałem tylko na dyskach SAS, która zmusza dysk do obejścia pamięci podręcznej i zapisu bezpośrednio na dysk. Poza tym istnieją bariery zapisu, które są mechanizmem zapewnianym przez jądro, które mogą wyzwalać opróżnianie pamięci podręcznej na dysku. Wymusza to zapisanie całej pamięci podręcznej, a nie tylko krytycznych danych, co spowalnia cały system w przypadku nadużycia, na przykład za pomocą fsync ().

Następnie są dyski z błędami oprogramowania układowego lub umyślnie kłamią na temat fizycznego zapisu danych.

Powiedziawszy to ... istnieje kilka sposobów konfiguracji napędów / systemów plików: A) NCQ i pamięć podręczna zapisu wyłączona B) Właśnie włączona obsługa NCQ C) Tylko pamięć podręczna zapisu włączona D) Zarówno NCQ, jak i pamięć podręczna zapisu

Zakładam, że bariery są włączone. BTW, jak sprawdzić, czy faktycznie są włączone?

W przypadku utraty zasilania, podczas aktywnego zapisu na dysk, domyślam się, że opcja B (NCQ, brak pamięci podręcznej) jest bezpieczna, zarówno dla dziennika systemu plików, jak i danych. Może wystąpić kara za wyniki.

Opcja D (pamięć podręczna NCQ +), jeśli używa się barier lub FUA, byłaby bezpieczna dla dziennika systemu plików i aplikacji korzystających z fsync (). Byłoby źle dla danych, które czekały w pamięci podręcznej, a system plików musi je wykryć (suma kontrolna), a przynajmniej system plików nie będzie (mam nadzieję) w niestabilnym stanie. Pod względem wydajności powinno być lepiej.

Moje pytanie brzmi jednak ... Czy coś mi brakuje? Czy jest jakaś inna zmienna, którą należy wziąć pod uwagę? Czy jest jakieś narzędzie, które mogłoby to potwierdzić i że moje dyski zachowują się tak, jak powinny?

julianjm
źródło
Jaka jest aplikacja w twojej sytuacji? Pomijasz wpływ lub wpływ kontrolera RAID i jego pamięci podręcznej na konfigurację. Na jakim systemie operacyjnym się również koncentrujesz? Który system plików rozważasz?
ewwhite
Brak konkretnej aplikacji. Od lat używam oprogramowania raid1, ale nigdy nie zagłębiam się w problem związany z pisaniem pamięci podręcznych. Ponadto, przejrzenie btrfs, dla którego nie ma jeszcze niezawodnego fsck, każe mi zadać pytanie, co mogę zrobić, aby zapobiec korupcji, gdybym go używał.
julianjm,
1
Zamiast tego używaj ZFS na Linuksie i sprzęż je z specjalnie zaprojektowanym urządzeniem ZIL. Używam DDRDrive dla systemów ZFS :)
ewwhite
Czy używasz ZFS z FUSE?
julianjm
2
Pamiętaj, aby uzyskać UPS.
Michael Hampton

Odpowiedzi:

11

W przypadku prostych systemów Enterprise istnieje dodatkowa warstwa w postaci adaptera pamięci (prawie zawsze karta RAID), na której istnieje jeszcze inna warstwa pamięci podręcznej. Jest dużo abstrakcji w pamięci stosu tych dni, i poszedłem do głębokiego szczegółowo w tym w serii blogu zrobiłem na Know Your I / O .

Karty RAID mogą ominąć pamięć podręczną na dysku, z których niektóre pozwalają nawet przełączać tę funkcję w systemie RAID BIOS. Jest to jeden z powodów, dla których dyski Enterprise są Enterprise, ich oprogramowanie wewnętrzne pozwala na takie rzeczy, których dyski konsumenckie ( szczególnie dyski „zielone”) nie. Ta funkcja odnosi się bezpośrednio do przypadku, o który się martwisz: awarii zasilania przy niezatwierdzonych zapisach. Pamięć podręczna karty RAID, która powinna być zasilana bateryjnie lub z pamięcią flash, zostanie zachowana do momentu przywrócenia zasilania i ponownego zapisu.

Niektóre dyski SSD dla przedsiębiorstw zawierają kondensator z wystarczającą mocą wystarczającą do zatwierdzenia wbudowanej pamięci podręcznej przed całkowitym wyłączeniem.

Jeśli pracujesz z systemem z dyskami bezpośrednio podłączonymi do płyty głównej, masz mniej zapewnień. O ile same dyski nie mają możliwości wykonania pamięci podręcznej zapisu, awaria zasilania rzeczywiście spowoduje utratę. System plików zyskał reputację zawodności z powodu niemożności przetrwania tylko w tym trybie awarii; Zaprojektowano go do pracy na pełnych systemach korporacyjnych z technologiczną możliwością przeżycia pamięci.

Jednak czas się zmienił i XFS został zaprojektowany tak, aby przetrwać. Inne główne systemy plików Linux (a także w systemie Windows) miały już inżynierię, aby przetrwać w tym trybie awarii. To, jak powinno działać, polega na tym, że utracone zapisy nie pojawią się w dzienniku FS i będą wiedzieć, że nie zostały zaangażowane, więc korupcja zostanie bezpiecznie wykryta i obejść ten problem.

Wskazujesz tutaj na jeden problem: oprogramowanie układowe dysku, które leży. W takim przypadku dziennik FS przyjmie błędne założenie w stosunku do rzeczywistości, a korupcja może nie zostać wykryta przez pewien czas. Parzystość RAID i lustrzana macierz RAID mogą obejść ten problem, ponieważ należy pobrać inną zatwierdzoną kopię. Ale konfiguracje pojedynczych dysków nie będą miały tej kontroli krzyżowej, więc faktycznie będą powodować błędy.

Aby uniknąć ryzyka związanego z oprogramowaniem układowym, należy zastosować dyski klasy korporacyjnej, które uzyskują znacznie większą weryfikację (i są testowane w porównaniu z przypuszczalnymi wzorcami obciążenia), oraz projektując system pamięci masowej, aby mógł przetrwać takie nieprawdy.

sysadmin1138
źródło
Rozumiem, że w przypadku sprzętowej macierzy RAID buforowanie zależy od kontrolera (mam nadzieję, że jest zasilany bateryjnie) i wskazane jest wyłączenie rzeczywistej pamięci podręcznej dysków. W moim przypadku (nie wspomniałem o tym) używam raidu programowego. Wygląda na to, że pamięć podręczna zapisu nie jest zalecana, ponieważ spowoduje utratę danych. Może nie katastrofalne (uszkodzenie systemu plików), ale i tak utrata danych. Na razie powstrzymam się od migracji mojego softraid1 + ext4 do btrfs + raid1. :)
julianjm
RAID nie pomaga w tym, ponieważ dane mogą równie łatwo znajdować się na obu dyskach i zapisywać pamięci podręczne jak jeden dysk.
psusi
@psusi Nie jest to ograniczenie w 100%, ale zapewnia dodatkową ochronę. To problem z czasem. Poszczególne implementacje RAID różnią się.
sysadmin1138
To wcale nie jest łagodzenie. Drugi dysk w ogóle nie ma znaczenia, ponieważ w przypadku awarii pierwotna kopia zapasowa zostanie skopiowana na drugą pamięć w celu odzyskania. Dlatego wracasz do tego, czy zapis trafił na (pierwszy) dysk, czy nie.
psusi
3

Dziennik systemu plików początkowo czekał na zakończenie zapisu w dzienniku przed wydaniem zapisu do metadanych, przy założeniu, że nie było pamięci podręcznej zapisu dysku. Przy włączonym buforowaniu zapisu dysku założenie to jest zepsute i może powodować utratę danych. W ten sposób powstały bariery. Dzięki barierom dziennik może upewnić się, że zapis do dziennika zostanie zakończony przed zapisem do metadanych, nawet jeśli dysk korzysta z buforowania zapisu. W warstwie sterownika dysku bariera wymusza opróżnianie pamięci podręcznej dysku przed wysłaniem kolejnych operacji we / wy, gdy napęd zgłasza, że ​​ma pamięć podręczną zapisu i jest włączony. W przeciwnym razie nie jest to konieczne, więc bariera po prostu uniemożliwia wydanie kolejnego IO do napędu, dopóki poprzednie IO nie zostanie zakończone. NCQ oznacza po prostu, że może być konieczne poczekanie na więcej niż jedno oczekujące żądanie, zanim zostanie wydane więcej.

psusi
źródło
Myślę, że bariery chronią cię przed uszkodzeniem dziennika (jeśli system plików tego zażąda), ale nie jestem pewien co do rzeczywistych danych w plikach ... Wydanie pamięci podręcznej po każdym zapisie uczyniłoby pamięć podręczną zapisu bezużyteczną, prawda? ?
julianjm
@ julianjm, oczywiście ... buforowane dane pliku są zawsze tracone w przypadku awarii, z NCQ lub bez pamięci podręcznej zapisu dysku.
psusi