Czy dysk zapisuje atomowe?

Myślę, że rozdarte strony nie są problemem. O ile wiem, wszystkie napędy mają wystarczającą ilość energii, aby zakończyć pisanie bieżącego sektora, gdy zasilanie zawodzi.

Problem polega na tym, że wszyscy kłamią.

Przynajmniej jeśli chodzi o bazę danych wiedząc, kiedy transakcja została dokonana na dysku, wszyscy kłamią. Baza danych wydaje fsync, a system operacyjny powraca tylko wtedy, gdy wszystkie zaległe zapisy zostały zapisane na dysku, prawda? Może nie. To powszechne, zwłaszcza z kartami RAID i / lub dyskami SATA, aby twój program był informowany o wszystkim (czyli o powrocie fsync), a mimo to na dysku nie ma jeszcze danych.

Możesz spróbować użyćDiskchecker Brada , aby dowiedzieć się, czy platforma, której użyjesz do swojej bazy danych, może przetrwać wyciągnięcie wtyczki bez utraty danych. Podsumowując: jeśli diskchecker zawiedzie, platforma nie jest bezpieczna dla uruchomienia bazy danych. Bazy danych z ACID polegają na wiedzy, kiedy transakcja została zrealizowana do sklepu, a kiedy nie. To prawda, czy bazy danych używają loginu z wyprzedzeniem zapisu (i jeśli baza danych powróci do Użytkownika bez wykonania fsync, wtedy transakcje mogą zostać utracone w przypadku awarii, więc nie powinna twierdzić, że dostarcza semantyki ACID).

Jest długi wątek na liście mailingowej Postgresql omawiający trwałość. Zaczyna mówić o dyskach SSD, ale potem dostaje się do dysków SATA, dysków SCSI i systemów plików. Możesz zaskocz się, aby dowiedzieć się, jak narażone mogą być Twoje dane na utratę. Jest to dobry wątek dla każdego, kto ma bazę danych, która potrzebuje trwałości, nie tylko tych, którzy korzystają z Postgresql.

Nie, nie są. Co gorsza, dyski mogą kłamać i mówić, że dane są zapisywane, gdy w rzeczywistości znajdują się w pamięci podręcznej dysku, w ustawieniach domyślnych. Ze względu na wydajność może to być pożądane (rzeczywista trwałość jest o rząd wielkości wolniejsza), ale oznacza to, że jeśli stracisz zasilanie, a pamięć podręczna dysku nie zostanie fizycznie zapisana, Twoje dane znikną.

Rzeczywista trwałość jest zarówno Twarda jak i powolna niestety, ponieważ trzeba wykonać co najmniej jeden pełny obrót na zapis, czyli 2 + z / align = "left" / Ogranicza to do kilkuset transakcji DB na sekundę i wymaga wyłączenia buforowania zapisu na dość niskim poziomie.

Dla celów praktycznych, jednak różnica nie jest , że duża sprawa w większości przypadków.

Zobacz:

• Jak (nie) osiągnąć trwałość.
• FSync () może nie spłukiwać dysku

Wydaje się, że ludzie nie zgadzają się co do tego, co dzieje się podczas pisania sektorowego, jeśli zasilanie zawodzi. Może dlatego, że zależy to od używanego sprzętu, a nawet systemu plików.

Z Wikipedii ( http://en.wikipedia.org/wiki/Journaling_file_system):

Niektóre dyski gwarantują zapis atomiczność podczas awarii zasilania. Inni jednak mogą przestać pisać w połowie drogi przez sektor po zasilaniu jest utracone, pozostawiając ją niedopasowaną do jego kod korygujący błędy. Na Sektor jest więc uszkodzony i jego zawartość utracona. Dziennik fizyczny strzeże przed takimi korupcja, ponieważ posiada pełną Kopia sektora, który może powtórka nad korupcją w następnym na górę.

Wydaje się sugerować, że niektóre dyski twarde nie zakończą zapisu sektora, ale że system plików dziennika może chronić Cię przed utratą danych tak samo jak xlog chroni bazę danych.

Z listy dyskusyjnej jądra Linuksa w dyskusji na temat dziennika ext3 system plików:

W każdym przypadku suma kontrolna bad sector wynosi błąd sprzętowy. Zapis sektorowy ma być być atomowym, albo się zdarza albo nie.

Raczej bym w to uwierzył przez komentarz wiki. Właściwie, samo istnienie bazy danych (firebird) bez xlog sugeruje, że zapis sektora jest atomowy, że nie może zatrzasnąć danych, których nie chciałeś zmienić.

Jest sporo dyskusji tutaj na temat atomiczności sektora pisze, i znowu brak porozumienia. Ale ludzie, którzy się nie zgadzają, zdają się mówić o zapisach wielosektorowych (które nie są atomowe na wielu współczesnych dyskach twardych.) Ci, którzy mówią, że sektor pisze są atomowe, wydają się wiedzieć więcej o tym, o czym mówią.

Odpowiedź na pierwsze pytanie zależy od sprzętu. Przynajmniej w przypadku starszego sprzętu odpowiedź brzmiała tak - awaria zasilania może spowodować zapisanie go na dysk. Większość obecnych dysków ma jednak wbudowany nieco "UPS"w sam dysk - kondensator, który jest wystarczająco duży, aby zasilać dysk wystarczająco długo, aby zapisać dane w pamięci podręcznej na dysku na talerzu. Mają również obwody do wykrywania, czy zasilacz jest nadal dobry, więc gdy moc robi się flaky, zapisują dane w pamięci podręcznej na talerzu i ignorują śmieci, które mogą otrzymać.

Jeśli chodzi o" rozdartą stronę", typowy dysk akceptuje tylko polecenia do zapisu całego sektora naraz, więc to, co otrzymasz, będzie zwykle integralną liczbą sektorów napisanych poprawnie, a inne pozostaną niezmienione. Jeśli jednak używasz logicznego rozmiaru strony, który jest większy niż pojedynczy Sektor, z pewnością możesz skończyć ze stroną, która jest częściowo napisana.

Że, dotyczy to jednak przede wszystkim bezpośredniego podłączenia do zwykłego dysku twardego typu moving-platter. Z prawie wszystkim innym, zasady mogą i często będą różne. Dla oczywistego przykładu, jeśli piszesz przez sieć, jesteś głównie na łasce używanego protokołu sieciowego. Jeśli przesyłasz dane przez TCP, dane, które nie pasują do CRC, zostaną odrzucone, ale te same dane przesyłane przez UDP, z tym samym uszkodzeniem, mogą zostać zaakceptowane.

Podejrzewam, że to założenie jest błędne.

Nowoczesne dyski twarde kodują dane w sektorach - i dodatkowo chronią je za pomocą ECC. Dlatego możesz skończyć z garbaging całą zawartość sektora - to po prostu nie ma sensu z kodowania używane.

Jeśli chodzi o coraz bardziej popularne dyski SSD, sytuacja jest jeszcze bardziej makabryczna - blok jest czyszczony przed nadpisaniem, więc, w zależności od używanego oprogramowania sprzętowego i ilości wolnego miejsca, całkowicie niepowiązane sektory mogą być uszkodzony.

Nawiasem mówiąc, awaria systemu operacyjnego nie doprowadzi do uszkodzenia danych w jednym sektorze.

Spodziewałbym się, że jedna podarta strona będzie składać się z części X, Części Y i części nieczytelnego sektora. Jeśli głowica znajduje się w środku pisania sektora, gdy zasilanie nie działa, napęd powinien natychmiast zaparkować głowice, tak aby reszta napędu (poza tym jednym sektorem) pozostała nieuszkodzona.

W niektórych przypadkach spodziewałbym się kilku podartych stron składających się z części X i części Y, ale tylko jedna podarta strona zawierałaby nieczytelny Sektor. Powodem kilku podartych stron jest to, że napęd może bufor wielu zapisów wewnętrznie, a kolejność zapisu może przeplatać różne sektory z różnych stron.

Czytałem sprzeczne historie o tym, czy nowy zapis do nieczytelnego sektora sprawi, że będzie ponownie czytelny. Nawet jeśli odpowiedź brzmi tak, to będą to nowe dane Z, ani X, ani Y.

Podczas aktualizacji dysk, jedyną gwarancją producenta jest to, że pojedynczy 512- zapis bajtowy jest atomowy (tzn. albo w całości, albo nie kompletne w ogóle); tak więc, jeśli dojdzie do przedwczesnej utraty mocy, tylko część większy zapis może się zakończyć (czasami nazywany rozdartym zapisem).