Jakiej opcji montowania użyć w systemie plików ext3, aby zminimalizować utratę lub uszkodzenie danych?

Mam osadzoną konfigurację za pomocą initramfs dla głównego systemu plików, ale za pomocą niestandardowej partycji ext3 zamontowanej na dysku flash IDE. Ponieważ integralność danych w obliczu utraty zasilania jest najważniejszym czynnikiem w całej instalacji, użyłem następujących opcji do zamontowania (poniżej jest wpis z mojego /etc/fstabpliku

<file system> <mount pt> <type> <options>                         <dump><pass>
/dev/sda2     /data      ext3   auto,exec,relatime,sync,barrier=1 0     2

Przyszedłem przez te opcje z czytania w Internecie. Martwię się, że treść /proc/mountspoda następujące informacje:

/dev/sda2 /data ext3 rw,sync,relatime,errors=continue,user_xattr,acl,
barrier=1,data=writeback 0 0

Z tego, co rozumiem po przeczytaniu, jest to, że chcę użyć data=journalopcji dla mojego montowania, ponieważ zapewnia to najlepszą ochronę przed uszkodzeniem danych. Jednak ze strony podręcznika dla określonych opcji ext3 mountmówi, co następuje o opcji zapisu:

Kolejność danych nie jest zachowywana - dane mogą zostać zapisane w głównym systemie plików po tym, jak ich metadane zostaną zapisane w dzienniku.
Mówi się, że jest to opcja o największej przepustowości. Gwarantuje to integralność wewnętrznego systemu plików , jednak może pozwolić na pojawienie się starych danych w plikach po awarii i przywróceniu dziennika.

Jestem bardzo zdezorientowany - strona podręcznika wydaje się sugerować, że dla integralności systemu plików chcę podać data=writebackopcję, mountale większość innych referencji, które znalazłem (w tym niektóre opublikowane książki na temat osadzonego linuksa) sugerują, że powinienem używać data=journal. Jakie byłoby najlepsze podejście dla mnie? Szybkość zapisu w ogóle nie stanowi problemu - zachowana jest jednak integralność danych.

Nie daj się zwieść faktowi, że tylko writebackwspomina internal filesystem integrity.
Za pomocą ext3, niezależnie od tego, czy używasz journal, orderedczy writebackmetadane systemu plików są zawsze rejestrowane w dzienniku, co oznacza integralność wewnętrznego systemu plików.

Te tryby danych oferują sposób kontroli nad tym, jak zwykłe dane są zapisywane w systemie plików.
Wwriteback trybie zmiany metadanych są najpierw rejestrowane w dzienniku i zapisywany jest blok zatwierdzania. Po zaktualizowaniu czasopisma mogą być kontynuowane zapisywanie metadanych i danych. data=writeback może stanowić poważne zagrożenie bezpieczeństwa: jeśli system ulegnie awarii podczas dołączania do pliku, po zatwierdzeniu metadanych (i przydzieleniu dodatkowych bloków danych), ale przed zapisaniem danych (bloki danych nadpisane nowymi danymi), to po kronice odzyskanie tego pliku może zawierać bloki wypełnione danymi z wcześniej usuniętych plików - od dowolnego użytkownika ¹ .

Tak więc, jeśli integralność danych jest twoim głównym zmartwieniem, a szybkość nie jest ważna, data=journaljest to droga.

Jak już zauważyłeś, głównym punktem jest to, że nie można zapobiec awarii systemu plików.

Co możesz zrobić:

1. Po stronie oprogramowania możesz używać fdatawrites po każdej ważnej operacji (zobacz ten post z 2003 roku autorstwa Theodore T'so, głównego programisty jądra Linux FS. To nadal prawda. Istnieje również taki o poważnej utracie danych ukrytej w starszych wersjach ext4)
2. Skróć interwał zatwierdzania do 1 sekundy ( commit = 1 ) (zobacz ten artykuł z LWN, chodzi o ext4, ale zawiera naprawdę przydatne informacje o ext3). NB: Nie powinno być potrzebne, z synchronizacji .
3. Jak powiedział RHEL doc wskazany przez sim, użyj * data_err = abort * i data = uporządkowany
4. noatime ograniczy bezużyteczne operacje na systemie plików
5. Jak już zauważyłeś, bariera = 1 jest dobrym sposobem na zminimalizowanie utraty danych (patrz ten post )
6. I synchronizacja jest także, oczywiście, jedną z opcji „Nie chcę stracić moich danych”.

Na koniec opcje montażu paranoikalnego mogą wyglądać następująco:

auto,exec,relatime,sync,barrier=1,commit=1,data=ordered,data_err=abort,noatime,

Możesz także zapewnić integralność danych dzięki automatycznemu programowi fsck przy każdym uruchomieniu.

Spróbuj zmienić część strony man, którą empahsize:

odpisać

Kolejność danych nie jest zachowywana - dane mogą zostać zapisane w głównym systemie plików po tym, jak ich metadane zostaną zapisane w dzienniku. Mówi się, że jest to opcja o największej przepustowości. Gwarantuje to integralność wewnętrznego systemu plików, jednak może pozwolić na pojawienie się starych danych w plikach po awarii i przywróceniu dziennika.

Jak zauważył don_crissti, inne tryby nie mają „jednak”.