Zapobiegaj uszkodzeniu danych na dysku ext4 / Linux po utracie zasilania

Mam wbudowane płyty z biosami American Megatrends z wbudowanym linuksem jako system operacyjny. Problem, który mam, polega na tym, że przemysłowe lampy błyskowe zostaną uszkodzone w wyniku utraty zasilania. Mam je sformatowane jako ext4. Ilekroć tak się dzieje, zwykle mogę naprawić flash za pomocą fsck, ale nie będzie to możliwe w naszych wdrożeniach. Słyszałem, że wyłączenie buforowania zapisu powinno pomóc, ale nie wiem, jak to zrobić. Czy jest jeszcze coś, co powinienem zrobić?

Więcej informacji

Napęd to moduł pamięci flash 4 GB. Mam jedną partycję, która jest ext4. System operacyjny jest zainstalowany na tej partycji, a grub jest moim programem ładującym.

fdisk -l pokazuje / dev / sda jako mój moduł flash z / dev / sda1 jako moją partycją podstawową.

Po utracie zasilania zwykle nie mogę zrobić tego całkowicie za pomocą skryptów inicjujących rozruch.

Kiedy montuję dysk na innym komputerze, uruchamiam fsck / dev / sda1. Zawsze pokazuje wiadomości takie jak

"zero datetime on node 1553 ... fix (y)?"

Naprawiam je i ładuje się dobrze do następnej utraty zasilania.

Kiedy jutro przyjdę do biura, opublikuję rzeczywistą wydajność fdisk -l

To wszystko, co wiem o tym, jak działa system. Nie jestem facetem od systemów, jestem inżynierem oprogramowania, który ma zwyczaj wpadania w kłopoty, które są poza jego opisem stanowiska. Wiem, jak formatować dyski, instalować program ładujący, pisać oprogramowanie i hakować w systemie operacyjnym.

Oto dane wyjściowe z dumpe2fs

#sudo dumpe2fs /dev/sda1
dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name:   VideoServer
Last mounted on:          /
Filesystem UUID:          9cba62b0-8038-4913-be30-8eb211b23d78
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              245760
Block count:              977949
Reserved block count:     48896
Free blocks:              158584
Free inodes:              102920
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      239
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Fri Feb  4 15:12:00 2011
Last mount time:          Sun Oct  2 23:48:37 2011
Last write time:          Mon Oct  3 16:34:01 2011
Mount count:              2
Maximum mount count:      26
Last checked:             Tue Oct  4 07:44:50 2011
Check interval:           15552000 (6 months)
Next check after:         Sun Apr  1 07:44:50 2012
Lifetime writes:          21 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Default directory hash:   half_md4
Directory Hash Seed:      249d2b79-1e20-49a3-b324-6cb631294a63
Journal backup:           inode blocks

Pamięć podręczna zapisu zwykle nie ma nic wspólnego z BIOS-em, przeważnie nie ma opcji przełączania ustawień pamięci podręcznej dysku. W Linuksie używanie hdparm -W 0powinno pomóc.

Ustawienie jest trwałe, więc jeśli nie masz hdparma do zabawy w systemach produkcyjnych, powinieneś być w stanie wyłączyć pamięć podręczną zapisu na dysku w innym systemie i ponownie zainstalować dysk.

BTW: Poparłbym pomysł, aby nie zapisywać głównego systemu plików (aby twój system mógł uruchomić się w rodzaju „trybu odzyskiwania” i pozwolić na zdalny dostęp, nawet jeśli z jakiegoś powodu nie można zamontować zapisywalnego systemu plików). A jeśli możesz zmienić projekt sprzętu, rozważ użycie urządzeń mtd zamiast dysków IDE / SATA z systemem plików obsługującym pamięć flash, takim jak jffs2 . Używamy tej kombinacji z kilkoma urządzeniami wbudowanymi (głównie w terenie rozwiązania routera VPN w terenie) od kilku lat z dobrymi wynikami.

Aktualizacja: źródłem problemu wydaje się być to, że używasz systemu plików ext4 z wyłączonym kronikowaniem - has_journalbrakuje go na Filesystem featuresliście. Po prostu zamknij wszystkie usługi, sprawdź, czy coś jeszcze ma otwarte pliki lsof +f -- /, zamontuj ponownie partycję główną tylko do odczytu mount -o remount,ro /, włącz dziennik tune2fs -O has_journal /dev/sda1i ustaw tryb dziennika „zamówiony” jako domyślną opcję montowania tune2fs -o journal_data_ordered /dev/sda1- będziesz musiał ponownie uruchom fsck (najlepiej z systemu ratunkowego) i ponownie podłącz root / restart po tej operacji.

Dzięki tym ustawieniom metadane mogą zostać odzyskane z dziennika nawet w przypadku nagłej awarii zasilania. Rzeczywiste dane są również konsekwentnie zapisywane na dysku, chociaż możesz zobaczyć dane z kilku sekund przed utratą zasilania podczas uruchamiania. Jeśli nie jest to do zaakceptowania, możesz rozważyć użycie tune2fs -o journal_data /dev/sda1opcji montowania z systemem plików - obejmowałoby to wszystkie dane zapisane na dysku w dzienniku - to oczywiście dałoby lepszą spójność danych, ale kosztem obniżenia wydajności i wyższego poziomu zużycia na dysku SSD.

Sugestia pamięci podręcznej zapisu to dobry początek, ale brzmi to jak wada projektu architektonicznego. W systemie wbudowanym prawdopodobnie nie należy montować wewnętrznej lampy błyskowej R / W, z wyjątkiem rzadkich przypadków. Naprawdę powinieneś wykonywać większość pracy w systemie plików pamięci i synchronizować zmiany z powrotem do pamięci flash RW po wydaniu polecenia przez użytkownika lub w regularnych odstępach czasu. Naprawdę rzadko zdarza się, aby system osadzony używał zwykłego systemu plików (takiego jak ext4) w trybie rw podczas normalnej pracy. Jeśli jest jakieś wymaganie aplikacji, w którym potrzebujesz dużo miejsca do przechowywania, powinieneś rozważyć inną partycję systemową i zaprojektowanie jej w taki sposób, aby partycja danych mogła być fsck -y'ed w ramach uruchamiania.

Jeśli potrzebujesz kilku punktów wyjścia, przyjrzałbym się, jak ludzie konfigurują bezdotykowe systemy Linux:

http://frank.harvard.edu/~coldwell/diskless/

i zacznij od tego. Ogólny pomysł polega na tym, że pliki binarne i dane systemowe można montować tylko do odczytu, aby system plików nie został uszkodzony. Jednak musisz być w stanie pisać w niektórych obszarach, więc potrzebujesz czegoś, co zwykle pamięci system plików / tmp, / var / tmp. Nawet jeśli pewne rzeczy muszą być zapisywalne, wystarczy utworzyć skrypt, aby zamontować partycję jako r + w, a następnie zatwierdzić zmiany, a następnie wrócić do trybu tylko do odczytu.

Naprawdę doskonałym tego przykładem jest sprzęt Cyclades, jego osadzony linux i za każdym razem, gdy wprowadzasz zmiany w konfiguracji, musisz wykonać skrypt zapisu, który faktycznie ponownie konfiguruje i zapisuje je do pamięci flash.