2010-07-21 26 views
6

Próbuję zaimplementować mechanizm przechowywania plików, który przechowuje wiele rekordów o zmiennym rozmiarze w jednym pliku z gwarancją, że zestaw rekordów zawsze będzie można odzyskać w stanie spójnym, nawet jeśli system nie działał poprawnie na sprzęcie poziom.Czy dane w pliku odwzorowanym w pamięci są gwarantowane do sekwencyjnego przepłukiwania?

Do tej pory każdy system, który wpadł mi w ręce, na sekwencję zapisu danych. Niektóre dane zostaną dołączone na końcu każdego rekordu, co potwierdza, że ​​zapis się powiódł. Jednakże, jeśli dane niekoniecznie są zapisywane na dysku sekwencyjnie po przepłukaniu, wówczas dane potwierdzające mogą być zapisane przed danymi treści.

Istnieją dwa oczywiste sposoby obejścia tego, ale oba są niepożądane:

  1. przepłukać zawartość, a następnie napisać potwierdzenie i opróżnić go. Dodanie dodatkowego koloru może pogorszyć wydajność.
  2. Dołącz sumę kontrolną do potwierdzenia (wymagałoby przeczytania treści w celu potwierdzenia jej ważności).

używam C# w systemie Windows (32- i 64-bitowy) i pamięci odwzorowany realizację

+0

Drugi pomysł (weryfikacja danych , znacznik czasu, numer porządkowy i suma kontrolna) wydaje się być zgodny z prawem. Generalnie jednak powinieneś szukać klastrów wysokiej dostępności z oddzielnymi maszynami w sieci. Wszystkie zapisy lub zapisy w dzienniku muszą być replikowane w sieci na dwie lub więcej maszyn. Nie można wyodrębnić żadnej gwarancji z jednego komputera, kropka. – rwong

Odpowiedz

1

Netto 4.0 jest plik ten jest zbyt niski poziom i OS specyficzne dla C#. spróbuj użyć Windows API z C i przeczytaj uważnie specyfikacje API.

0

Czy próbowałeś użyć FileOptions.WriteThrough dla podstawowego strumienia plików? To może pomóc, ponieważ wyłącza buforowanie. Inne pomysły polegałyby na zachowaniu oddzielnego pliku zawierającego potwierdzenia jako ostatnie pisemne przesunięcie, jeśli nie pasuje do rozmiaru pliku (na przykład z powodu przerwy w zasilaniu) można po prostu skrócić to do tego rozmiaru

+1

To są dobre pomysły w zakresie odzyskiwania błędów. Niestety nie mają one zastosowania do plików mapowanych w pamięci. Pliki MM zawsze mają wyłączone WriteThrough, ponieważ używają bazowego menedżera stron OS do obsługi buforowania. Prowadzenie dziennika potwierdzeń jest również dobrym pomysłem, ale ma inne problemy. Wymagałoby to dwóch opróżnień na operację na jednym pliku (jeden dla pliku MM, drugi dla dziennika). Jeszcze bardziej problematyczne, z plikami MM nie wiadomo, kiedy skończy się kolor. W najlepszym razie możesz poinstruować system operacyjny, aby rozpoczął kolor, ale nie otrzymasz potwierdzenia po ukończeniu. To sprawia, że ​​deterministyczny dziennik jest bezużyteczny. –

+0

@Kennet Belenky: Sprawa spłukiwania jest dziwna, porównaj z [Java] (http://docs.oracle.com/javase/1.4.2/docs/api/java/nio /MappedByteBuffer.html). Może mógłbyś użyć zwykłego FileOutputStream dla logu (log jest krótki, więc nie będzie dużej różnicy prędkości)? IIUYC tracąc niepotwierdzony rekord nie jest taki zły, więc można rzadziej spłukiwać dziennik. – maaartinus

+0

@maaartinus Java API jest zdecydowanie łatwiejsze do zrozumienia, ale nie jest też idealne. Fajnie, że zapewnia on gwarancję, że spływ zostanie zakończony po powrocie. Byłoby jednak jeszcze ładniej, gdyby dostarczył powiadomienie asynchroniczne, dzięki czemu mógłbyś zająć się swoją firmą. Czas próbkowania 10 ms w przypadku spłukiwania dysku wirującego to długi czas oczekiwania. –