Jaki system plików oferuje najlepszą ochronę w celu zabezpieczenia danych przed uszkodzeniem spowodowanym utratą zasilania?

Używam małej uClibci busyboxopartą systemu osadzonego na urządzeniu x86. Korzystam z initramfs, ale również instaluję ext3katalog niestandardowy na kompaktowym urządzeniu flash w trybie IDE, którego używam do przechowywania trwałych danych rejestrowania pomiarów utworzonych przez niestandardową pisaną aplikację c ++. Wybrałem ext3system plików, ponieważ jest on zalecany ze względu na bezpieczeństwo przed utratą zasilania podczas korzystania z napędów CF w trybie IDE w kilku książkach, które przeczytałem ( Budowanie systemów Linux wbudowanych przez Karima Yaghmoura i Embedded Linux Primer autorstwa Christophera Hallinana). Jest to szczególnie ważne, a dane mają kluczowe znaczenie.

Jednak ze względu na niektóre komentarze w moim poprzednim pytaniu Mylę się z tym, jak przywrócić uszkodzone pliki ext3, jeśli wystąpi przerwa w zasilaniu podczas zapisu pliku , wydaje się, że w rzeczywistości ten system plików nie oferuje gwarancji bezpieczeństwa przed uszkodzeniem danych z powodu zasilania utrata. Więc chciałbym wiedzieć, czy

1. Czy to ext3właściwie najlepszy wybór dla tej konfiguracji?
2. Czy utrata zasilania podczas operacji zapisu na dysku powoduje jedynie uszkodzenie części danych, które okresowo dołączam do pliku, czy może uszkodzić cały plik?
3. Czy dane, które nie są zapisywane w momencie utraty zasilania, są całkowicie bezpieczne? W szczególności, czy istnieje ryzyko, że mój initramfs.cpioplik może zostać uszkodzony również?
4. Czy jest jakaś metoda, której mogę użyć w kodzie aplikacji do ochrony danych (tj. Utworzenie dodatkowej partycji i zapisanie moich danych do obrazów lustrzanych, aby zawsze były 2 kopie) - szybkość nie jest prawdziwym problemem dla mojej aplikacji tak kosztowne operacje kopiowania są dopuszczalne.

Widziałem i czytałem odpowiedzi na to pokrewne pytanie: Czy systemy plików kronikowania gwarantują zapobieganie uszkodzeniom po awarii zasilania? , ale nie obejmuje niektórych rzeczy, które mnie dezorientują.

Zdaję sobie sprawę, że zadaję wiele pytań, ale wydaje się, że pomimo przeczytania dużej ilości materiałów, zasadniczo nie zrozumiałem ryzyka dla moich danych w przypadku utraty zasilania.

Podobnie jak w przypadku wszystkich kwestii związanych z bezpieczeństwem, nie ma żadnych gwarancji, ale musisz również zrównoważyć ryzyko (i koszty) z prawdopodobieństwem. Z doświadczenia (i prowadziłem dziesiątki * nix boxen od czasów ciemnych), nigdy tak naprawdę nie miałem znaczącego uszkodzenia systemu plików spowodowanego zasilaniem.

Niektóre z tych maszyn działały nawet na nielogowanych systemach plików (zazwyczaj ufs i ext2). Niektóre z nich były wbudowane, a kilka to telefony komórkowe, takie jak Nokia N900 - więc nie było gwarancji dobrego zasilania.

Nie chodzi o to, że uszkodzenie systemu plików nie może się zdarzyć, po prostu prawdopodobieństwo jego wystąpienia jest na tyle niskie, że nie powinno cię to martwić. Nadal nie ma powodu, aby nie zabezpieczyć swoich zakładów.

W odpowiedzi na twoje dosłowne pytania:

1. Przynajmniej pierwsza książka, do której się odwołałeś, została napisana wcześniej ext4- gdy autor sugeruje użycie ext3, naprawdę mówi „nie używaj niestabilnych lub nieudokumentowanych systemów plików takich jak ext2”). Spróbuj ext4, jest dość dojrzały i ma kilka przyzwoitych opcji dla nie obracających się dysków, które mogą przedłużyć żywotność twojego urządzenia flash.
2. Możliwe, że straciłbyś ostatni blok lub dwa, a nie cały plik. W przypadku rejestrowanego systemu plików będzie to jedyna strata. Istnieją scenariusze awarii, w których widziałem przypadkowe dane rozpylane w całym pliku, ale wydaje się, że są tak prawdopodobne, jak mikrometeoryt rozbijający się bezpośrednio na urządzenie osadzone.
3. Zobacz 2. Nic nie jest w 100% bezpieczne.

4. Jeśli masz drugi kanał IDE, włóż tam drugą kartę CF i od czasu do czasu rób kopię zapasową systemu plików. Istnieje kilka sposobów, aby to zrobić: rsync, cp dump, dd, nawet przy użyciu md(4)(oprogramowanie RAID) urządzenia (trzeba dodać drugi dysk sporadycznie, niech synchronizować, a następnie usunąć go - jeśli oba urządzenia znajdują się pod napięciem przez cały czas, działają one to samo ryzyko uszkodzenia systemu plików). Jeśli używasz LVM, możesz nawet pobierać migawki. W przypadku urządzenia osadzonego do gromadzenia danych po prostu użyłbym rozwiązania ad hoc, które montuje drugi system plików, kopiuje dziennik danych, natychmiast go odmontowuje. Jeśli martwisz się, że urządzenie ma dobry obraz rozruchowy, przyklej drugą kopię menedżera rozruchu i wszystkie niezbędne obrazy rozruchowe na drugim urządzeniu i skonfiguruj komputer do uruchamiania z dowolnej karty CF.

   Nie ufałbym drugiej kopii na tym samym urządzeniu, ponieważ urządzenia pamięci masowej ulegają awarii częściej niż stabilne systemy plików. Znacznie częściej, z mojego dotychczasowego doświadczenia (w pracy panował gorzki żart o niesamowicie wysokich szansach na awarie dysku w piątek po południu. Przez jakiś czas było to prawie cotygodniowe wydarzenie). Niezależnie od tego, czy dysk się kręci, może się nie powieść. Jeśli to możliwe, trzymaj jajka w dwóch koszach, a będziesz lepiej chronić swoje dane.

   Jeśli dane są szczególnie wrażliwe, regularnie odwiedzam urządzenie, wymieniam kopię zapasową CF na nową i uruchamiam ponownie, pozwalając fsckwszystkim jej systemom plików na dobrą miarę.

Wydaje mi się, że to, co implementacja systemu plików może osiągnąć w przypadku nagłej utraty zasilania, jest ograniczone - w rzeczywistości jest to sprzężenie ze sprzętem, więc co dzieje się między czasem, w którym wysyła dane / instrukcje do sprzętu, a czasem dostaje odpowiedź jest poza kontrolą. Gdyby istniał system plików, który mógłby obejść ten problem, słyszałbyś o tym.

Z tego powodu strategia ochrony danych krytycznych najbardziej skorzysta na decyzjach podejmowanych na poziomie sprzętowym , np. Przy użyciu zasilacza awaryjnego. Prawdopodobnie nie jest to wykonalne w twojej sytuacji.

Powiedziałeś, że wydajność nie jest tak naprawdę dużym problemem, więc rozważnie ją wykorzystaj fsync().

Czy utrata zasilania podczas operacji zapisu na dysku powoduje jedynie uszkodzenie części danych, które okresowo dołączam do pliku, czy może uszkodzić cały plik?

Od lat używam systemów plików extN osobiście i na serwerach internetowych o niskim natężeniu ruchu i podobnie jak Alexios nie widziałem dużej korupcji z powodu awarii zasilania (chociaż, szczerze mówiąc, serwery mają UPS i nie pamiętam jeden z nich schodzi w tę stronę). Znacznie poważniejszym problemem jest uszkodzenie spowodowane awarią sprzętu, które różne systemy plików mogą (ponownie) być w stanie coraz bardziej poradzić sobie z tym problemem, ale (ponownie) jest to zasadniczo poza ich kontrolą i nie mogą temu zapobiec.

Czasami widziałem pliki utracone lub obcięte do zera. Przypuszczam, że istnieje spora szansa, że ​​uda się je jakoś odzyskać; nie było to dla mnie konieczne, ponieważ zostały utworzone kopie zapasowe. Przez większość czasu fsckwydaje się, że coś jest nie tak .

Czy dane, które nie są zapisywane w momencie utraty zasilania, są całkowicie bezpieczne? W szczególności, czy istnieje ryzyko, że mój plik initramfs.cpio może zostać uszkodzony również?

Myślę, że ryzyko jest naprawdę bardzo niskie po awarii zasilania, z wyjątkiem tego, że uszkodzenie pamięci flash może być uzależnione od wzrostu mocy, który może towarzyszyć awariom zasilania - z którym nie mam doświadczenia, ale mam nadzieję, że pomyślałeś o i zbadałem to.

Czy w kodzie aplikacji mogę zastosować jakąkolwiek metodę ochrony danych?

Warto powtórzyć punkt o fsync () . Obiekty C ++ / iostream nie mają na to metody (:: flush i :: sync nie są fsync), ale wystarczy deskryptor pliku.

ZFS jest zdecydowanie systemem plików chronionym przed uszkodzeniem z założenia i prawdopodobnie jedynym. Nie jestem jednak pewien dostępności implementacji ZFS (opartych na bezpiecznikach lub natywnych) dla platform opartych na uClinux.

Istnieje co najmniej jeden komercyjny system plików, który wykonuje ogromną pracę, upewniając się, że system plików prawie nie może zostać uszkodzony z powodu awarii zasilania i że jedyne dane, które ryzykujesz utratą, to dane dodawane w momencie zaniku zasilania.

Wadą jest to, że jest bardzo droga, z drugiej strony oferują świetne wsparcie. Ze względu na koszty, to naprawdę tylko opcja dla wysokich stawek i / lub produktów o dużej objętości. Podobnie jak krytyczne urządzenia wbudowane np. W wydobycie ropy i gazu, które muszą zapewnić integralność systemu w „niepewnych” warunkach pracy (np. Częste przerwy w dostawie prądu itp.).

Sprawdź DataLight (firma) i / lub produkt „ Reliance NITRO ”. (Reliance to ich dziedzictwo i bezpieczne, ale niezbyt skuteczne rozwiązanie, zastąpione przez Reliance NITRO ). Nawet jeśli nie masz pieniędzy na korzystanie z tego systemu, mają kilka całkiem dobrych artykułów omawiających działanie ich systemu, dlaczego jest on bardziej niezawodny niż np. Ext3 i ext4.

Przepraszam, jeśli to brzmiało jak reklama, chciałem tylko wskazać opcje.