Czy to możliwe, że tylko jeden bit się przełącza, więc mój plik pokazuje mi literę „Q” zamiast „S”


22

W naszej aplikacji korzystamy z Hibernacji i PostgreSQL do przechowywania danych. W jednej z naszych tabel bazy danych mamy kolumnę dyskryminującą, która mówi na przykład „TIPPSPIEL”. Jest to stały ciąg znaków i nie może nim manipulować żaden użytkownik.

Nagle mieliśmy jeden wpis w tym ogromnym stole, w którym zamiast „TIPPSPIEL” mieliśmy „TIPPQPIEL”. Nie mamy pojęcia, jak to się może stać.

Czy jest możliwe w jakikolwiek sposób, że nasz dysk twardy zmienia jeden bit, więc nasza litera „S” nie jest już kodowana jako „1010001”, ale nagle staje się „Q” na dysku twardym z jednym przełączonym bitem w ten sposób: 1010011?

Nie jestem ekspertem w dziedzinie fizyki dysków twardych, ale sądzę, że system operacyjny lub dysk ma sumy kontrolne i inne rzeczy, aby upewnić się, że tak się nie stanie.

Czy to możliwe, że tylko jeden bit się przełącza, więc mój plik pokazuje mi literę „Q” zamiast „S”?

AKTUALIZACJA: Przeprowadziliśmy dalszą analizę. Nasza baza danych slave otrzymuje rekordy WAL od mastera (funkcja PostgreSQL). Cokolwiek: nasz serwer slave powinien być zsynchronizowany. Ale niewolnik nie był zsynchronizowany w tym konkretnym rzędzie. Widzieliśmy, że stało się to kilka dni temu bez interakcji użytkownika w tym konkretnym wpisie. Więc to MUSI być trochę przewracane. straszny!


Wolałbym założyć, że pochodzi to z wadliwej pamięci. Czy nadal masz dziennik, kiedy ta kolumna została napisana?
ott--

1
Jest mało prawdopodobne, ale możliwe, że bity w transporcie są odwracane z wysokim stopniem regularności, patrz „bitsquatting”
Sirch,

Odpowiedzi:


10

Tak rzadko widuje się naprawdę interesujące pytanie na tej stronie, więc przede wszystkim dziękuję.

Wydaje mi się, że to, co widzisz, to błąd jednobitowy. Zadziwiające, że możesz to zauważyć szczerze, ale masz rację zakładając, że drugi najmniej znaczący bit został przełączony (zakładając, że używasz ASCII tak czy inaczej).

Jeśli chodzi o sumy kontrolne itp., Kiedy zapisano je na dysku, prawdopodobnie zostanie to zweryfikowane w porządku - jestem prawie pewien, że problem ten rozwinął się później przez zwykły błąd upływu magnetycznego. Ale masz rację, przeprowadzane są kontrole kodowania, różni się to od producenta, ale prawdopodobnie jest gdzieś błąd mówiący „to wygląda trochę dziwnie” - ale jaką opcję ma twój łańcuch IO? odmówić ci całego bloku? Zakładam, że jest to pojedynczy dysk inny niż RAID, ponieważ dyski RAIDed mają zwykle więcej dostępnych opcji po wykryciu błędów.

To dziwne, choć tego rodzaju rzeczy prawdopodobnie zdarzały się wiele razy na sekundę na całym świecie.


1
Masz rację, w tym przypadku była to konfiguracja dysku innego niż RAID. jak wynika z mojej dalszej analizy, wydarzyło się to długo po napisaniu płyty.
Janning

1
Jeśli przez 20 lat jako administrator systemu widziałem 3 przypadki pojedynczego bitu. Tylko jeden z nich można udowodnić w 100%. Pozostałe 2 były podejrzane o bicie, nie mogliśmy powiedzieć z całą pewnością. (Bit mógł przerzucić pamięć po przeczytaniu pliku. Gdy zauważyliśmy rozbieżność, oryginalny plik nie był już dostępny lub został dotknięty. Jestem pewien, że zdarza się częściej niż wszyscy myślą, ale rzadko jest zauważany i zwykle nie da się tego udowodnić, jeśli zostanie zauważony
Tonny,

1
Niepowodzenie odczytu całego bloku jest dokładnie tym, co robią dyski, gdy otrzymają nieusuwalny błąd. Niemożliwe jest posiadanie tylko jednego bitu odwrócenia w części danych użytkownika sektora i pozostanie niezauważonym. Bit musiał zostać odwrócony, kiedy został zapisany na dysku.
psusi

Czy to pytanie powinno być kanoniczne?
Deer Hunter

@psusi Nie jest to niemożliwe, ponieważ po prostu potrzebujesz wystarczającej ilości bitów w sektorze, aby ECC wyszło poprawnie. Mało prawdopodobne, ale możliwe, a producenci dysków podają wystarczająco wysokie poziomy błędów, których naprawdę powinieneś się spodziewać. Słyszałem pogłoski, że ludzie je zobaczyć ZFS (ze względu na sumy kontrolne danych ZFS szczebla) ...
derobert
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.