Używanie Ext4 może prowadzić do utraty danych
- Dodano: 12 marca 2009
- Wprowadził: mith
- Komentarze: 126
Na stronie śledzącej błędy, dotyczące nadchodzącego wydania Ubuntu 9.04, zgłoszono problem częstej utraty danych podczas korzystania z systemu plików Ext4 – zbliżającego się wielkimi krokami nowego linuksowego standardu.
Raport opisuje utratę plików konfiguracyjnych w sytuacji, gdy KDE 4 zawiesi się tuż po starcie systemu. W ich miejscu pojawiają się zbiory o zerowym rozmiarze i równie niewielkiej przydatności.
Jak się okazuje, przyczyną problemu nie jest błąd programistów, odpowiedzialnych za nowy system plików, lecz raczej nawyki związane ze sposobem działania popularnego obecnie Ext3. Jego młodszy kuzyn zawiera wiele usprawnień, mających na celu zwiększenie wydajności zapisu danych. Jednym z najważniejszych jest wprowadzenie przerwy między wywołaniem operacji zapisania danych, a fizycznym umieszczeniem ich na nośniku. Przerwa ta może trwać od 45 do 150 sekund, podczas których system stara się zoptymalizować sposób umieszczenia plików na dysku, zbierając większe porcje danych do jednorazowej alokacji. Takie zachowanie pomaga zmniejszyć obciążenie procesora oraz oddala zagrożenie fragmentacji plików.
Problem pojawia się, gdy coś spowoduje zawieszenie się systemu w okresie między wywołaniem operacji zapisu, a umieszczeniem danych na nośniku. Z licznika wolnej przestrzeni dyskowej zostanie odjęta odpowiednia wartość, lecz dane mogą nie zostać skopiowane na czas z bufora, gdyż system wciąż czekał z ich alokacją. W ten właśnie sposób powstają pliki o zerowym rozmiarze. Dotyczy to w szczególności niewielkich zbiorów konfiguracyjnych – bardzo często otwieranych i zapisywanych.
Ted Ts’o, programista Ext4, który zajmuje się tym problemem, poinformował, że tak naprawdę podobna sytuacja mogła zdarzyć się również na partycjach Ext3, lecz prawdopodobieństwo jej wystąpienia było znacznie niższe, gdyż Ext3 alokowało pliki po maksymalnie 5 sekundach. Jego zdaniem wina leży po stronie niechlujnych programistów, którzy nie zadbali o to, by w krytycznych momentach dokonać przymusowej alokacji danych.
Twórcy Ext4 postanowili jednak opracować specjalną łatkę, której działanie polegać ma na wykrywaniu sytuacji, gdy plik otwierany jest z flagą O_TRUNC i wymuszaniu alokacji od razu po wywołaniu polecenia zapisu. Wiązać się to jednak będzie z utratą wydajności i nie jest perfekcyjnym rozwiązaniem, lecz tymczasowym sposobem na obejście problemu. Odpowiednia poprawka została już zgłoszona, lecz zostanie włączona dopiero do jądra 2.6.30. Nic chyba jednak nie stoi na przeszkodzie, by twórcy dystrybucji dołączyli ją na własną rękę do aktualnego kernela, co może być ważne, gdyż trzy duże systemy: Ubuntu, Mandriva oraz Fedora, które planowane są na kwiecień, zostaną wydane właśnie z jądrem 2.6.29.
Cała sytuacja spowodowała ostatnio sporo zamieszania. Warto jednak pamiętać, że nie jest ona dramatyczna – gdyż występuje tylko w przypadku zawieszenia się systemu, co nie zdarza się przecież na co dzień. Należy również pamiętać, że alokacja z opóźnieniem jest stosowana w kilku innych popularnych systemach plików. Wykorzystują ją między innymi chwalone powszechnie Reiser4, XFS oraz ZFS – a więc problem dotyczy ich w podobnym stopniu.
Szerszy opis w języku angielskim – szczególnie przydatny dla tych – których ciekawi dokładny opis mechanizmu powstawania obciętych plików, można znaleźć na blogu Ts’o (dzięki uprzejmości rjc).
Więcej informacji: http://www.h-online.com/open/Possible-da...ews/112821
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
126 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
Warto było by dodać link do bloga samego Ts'o i zobaczyć czego tak naprawdę dotyczy ten "problem".
Pisałem newsa głównie bazując na tym, co Ts'o napisał w bug trackerze, bo na tej stronie, gdzie o tym przeczytałem po raz pierwszy, trochę głupot stworzyli
Według nich w ogóle to KDE zawieszało system – a przynajmniej bez dokładnego wczytania – tak to wyglądało. Na szczęście Ts'o w trackerze opisał to po ludzku. A ja w zasadzie przepisałem jego słowa, choć mniej technicznie, a bardziej obrazowo pisząc, skąd się bierze obcinanie plików – myślę jednak, że skutecznie z tego wybrnąłem. Ludzie niezbyt interesujący się konkretnymi wywołaniami systemowymi chyba to docenią, natomiast zainteresowani mogą doczytać w trackerze (a teraz również na blogu). Zauważ zresztą, że naprawdę starałem się uniknąć wywołania taniej sensacji, zwrócić uwagę, co jest źródłem zamieszania i wyraźnie zaznaczyć, że nie jest to ani problem Ext4 wyłącznie, ani jakieś cudaczne zjawisko bez logicznego uzasadnienia.
O blogu nie wiedziałem, ale linka wrzucę oczywiście. Dzięki
Świetny news!
Kilka uwag.
Wspominasz o niechlujnych programistach – wypadalo by dodac iz chodzi o programistow aplikacji, a nie np. o programistow kernela, tudziez samych systemow plikow.
Druga, jakze wazna rzecz, o ktorej jednak nie wspominasz (a o ktorej pisze Ts'o) to zamkniete (binary only) sterowniki uzywane m.in. w Ubuntu, ktore to przyczyniaja sie (czy tez raczej powoduja) do tych powstawania tych bledow.
Ext4 to raczej mlodszy brat (vide rodzina ext), nie kuzyn Ext3 ;^)
Poza tym to calkiem dobry artykul.
Ale ReiserFS4 (czy XFS) nie gubi danych w ten sposób (kiedyś ponoć XFS, JFS miał ten problem), a ponoć Reiser to niechlujny programista bo jego FS nie jest częścią vaniliowego kernela, a budowa za bardzo wizjonerska i odjechana..
Co mają do tego zamknięte sterowniki? FS powinien być napisany tak by nie wymuszać w nich zmian, a tym bardziej że tu chodzi o zapisywanie konfiguracji przez programy wolne/otwarte, które do tego celu wykorzystują mechanizmy tylko od FS..
jak to nie, ReiserFS4 i ReiserFS ( nie ze tylko one ) tez maja tego typu problem, sam tego doswiadczylem i to nie raz.
Z ext4 tego nie doswiadczylem, ale to nic nie znaczy, po prostu u mnie ten blad nie wystapil, chocy z tego powodu ze mi 9.04 jeszcze nie padl.
A inne systemy plikow? Moze inaczej, ktory tego problemu nie ma? Ext3 tez ma problemy, XFS , itp itd.
Teraz juz nie pamietam dokladnie czy to ext3 czy reiser, mial ten blad, ze jak miejsce na dysku sie konczylo to system sie plikow sie posypal, za kazdym razem inaczej, raz bez wiekszych strat innym razem tracac wszystko. [ u mnie bodajze z ext3 wystapil ten blad ] . Bylo to jaksi czas temu, ale watpie by bylo poprawione.
Nie ma co narzekac na systemy plikow, tylko informowac o kazdym bledzie, bysmy byli swiadomi tego co moze sie stac.
@3ED: XFS mial zupelnie inny problem – w przeciwienstwie do tego z niusa rzeczywisty i bardzo powazny. Mianowicie potrafil zgubic dane z pliku, ktory _nie byl zapisywany_.
@3ED
Wpis Ts'o:
[...] This become especially noticeable on Ubuntu, which uses many proprietary, binary-only drivers, which caused some Ubuntu systems to become highly unreliable, especially for Alpha releases of Ubuntu Jaunty, with the net result that some Ubuntu users have become used to their machines regularly crashing. (I use bleeding edge kernels, and I don’t see the kind of unreliability that apparently at least some Ubuntu users are seeing, which came as quite a surprise to me.) [...]
Z moich doświadczeń, XFS w przypadku utraty zasilania, potrafił zachować metadane pliku (nazwa, daty modyfikacji), natomiast zawartością pliku często okazywały się same zera:/
Swoją drogą, czy system plików gwarantuje to, że dane zostaną fizycznie zapisane na nośniku bez wywołania sync(2) czy fsync(2)?
Tia tez to przerabialem XFS. To swietny FS ale jako system stworzony z mysla o serwerach pasuje przy nim zadbac o UPSa na desktopie.
O jak się rzuciliście do odpowiadania.. :>
Rzeczywiście XFS i nie zgubił mi ani razu nawet bajta danych.. Za to fajnie jest jak po [to już chyba ponad rok] zwolnił, a usuwanie plików trwa wieczność.. Reiser natomiast jak stał tak stoi, zero problemów, tylko po stworzeniu tego FS wykonuję kilka dodatkowych czynności jak np. dokładne skanowanie z przebudową (reiserfsck to kawał dobrej roboty w porównaniu z mkfs.reiserfs). Ten FS na /boot się nie zabardzo nadaje. Po padzie zasilania wstaje 50x wolniej aż do momentu wczytania modułu ale wiadomo, że na /boot najlepszy ext2.
> O jak się rzuciliście do odpowiadania.. :>
A to przez trasza,.
Btw. Zastanawiałem się nad wymianą FS z XFS na coś (reiser bo miałem najmniej z nim problemów) ale może coś doradzicie innego skoro ten jest zły, a ja się nie znam?
W tekscie sugerujesz jakoby to KDE4 bylo winne gubienia danych. A to jest nie prawda.
Sytuacja taka nie jest zalezna od tego jakich okienek sie uzywa tylko wynika z opóźnień w zapisie.
System nie zapisuje danych natychmiast na dysku tylko w cyklach – jesli w czasie "pauzy" wystapi jakis zonk to na dysku pozostana niezapisane miejsca.
(podobnie jek np z pendrakiem – jesli po skopiowaniu na pendrive plikow wyjmiemy go z kompa bez wczesniejszego odmontowania).
To jes coś okropnego jak się przejdzie z Windowsa, ile razy już nagrywałem coś na pendrive'a, a potem tego nie było.
Swoją drogą, to nie mogliby tego jakoś inaczej wymyślić?
@Bananikus
A przed wyciągnięciem pendrive'a odmontowywujesz system plików tego urządzenia? Wydaje mi się, że nie, bo jeśli byś to robił, system nie odmontowałby go dopóki nie zapisałby wszystkich danych. W ubunciaku dodatkowo wyskakuje informacja o aktualnie zapisywanych danych, a potem info o możliwości wyciągnięcia flasha z USB.
offtopic ale dla mnie ważny… od dawna przy odmontowaniu pendriva nie pojawia mi się ten komunikat o możliwości bepiecznego usunięcia urządzenia. Macie jakieś pomysły dlaczego ? (ubuntu 8.04, 2.6.24-24, gnome)
Prawdopodobnie jest to celowy zabieg, żeby nie uprzykrzać życia użytkownikowi. Jeśli jest inaczej i się mylę, to dodam, że też tak mam. Możliwe, że dzieje się tak tylko raz na czas trwania sesji albo system ma za zadanie poinformować użytkownika kilka razy, a potem powiadomienia zostają celowo wyłączone. Może odpowiedzialny za do demon- jest wyłączany przez system. Powód? Od którejś tam wersji jądra, wyłączane są usługi, żeby oszczędzać energię. Szczerze to nie wiem, że często się z tym spotykam
@osuz
On nie pojawia się zawsze; w szczególności, nie pojawia się, gdy dane zostały już dawno zapisane i nie ma na co czekać. Komunikat o możliwości wyjęcia pojawia się tylko wtedy, gdy wcześniej pokazał się komunikat informujący, by poczekać. Dlatego nie ma się co martwić.
Na brainstorm była kiedyś idea, by ten komunikat pokazywać zawsze, ale nie wiem, co się z nią stało.
Jasne, że odmontowuję, tylko, że mi się odmontowuje momentalnie. Po sekundzie, dwóch, a potem jeśli za szybko po odmnotwaniu wyjmę pendrive'a to kopiowane dane znikają.
dopisz sync
Żartujesz prawda? Jeszcze tego brakuje żeby przy odmontowywaniu pendrajwa trzeba bylo uruchamiać konsole i coś pisać. ps. SOA1
mgol@
jeszcze pociągnę temat… Podłączam Nokię z symbianem w trybie transmisji danych. Zostaje zamontowana karta pamięci, która jest w telefonie. Po jej odmontowaniu telefon nie sygnalizuje "można dołączyć kabel" co ma miejsce po "bezpiecznym usuwaniu" w Win. Pytanie: czy to jest kwestia współpracy symbiana z Win (i braku współpracy z Linuksem), czy też to odmontowanie de facto nic nie daje?
> W ubunciaku dodatkowo wyskakuje informacja o aktualnie zapisywanych
> danych, a potem info o możliwości wyciągnięcia flasha z USB.
Wydaje mi się, że to nie tylko w ubuntu jest możliwe, pewnie tam mają przekonfigurowany hal/dbus ale czy napewno to nie jest zwyczajny mechanizm gnome? (gnome-volume-manager)
osuz: w przypadku Nokii pomaga eject /dev/sdX. Wtedy dostaniesz ten komunikat.
@3ED
Raczej napewno jest tak jak piszesz, ale ja ten efekt zaobserwowałem właśnie w Ubuntu. W obecnej chwili posiadam OpenSuSE a na dodatek rzadko korzystam z pendrive'a, więc nie jestem w stanie potwierdzić tego dla innych distro.
@osuz: odmontowanie urządzenia na USB w Linuksie to tylko odmontowanie, nie wyłącza urządzenia. "Bezpieczne usuwanie" w Windowsach nie tylko odmontowuje, ale też wyłącza urządzenie – np. u mnie gaśnie lampka na pendrivie, która świeci się cały czas od momentu włożenia go do gniazdka. Prawdopodobnie stąd się bierze różnica – telefon najprawdopodobniej wykrywa wyłączenie, nie odmontowanie (nie bardzo zresztą wiem, jak mozna byłoby w wiarygodny sposób wykryć odmontowanie z poziomu *montowanego* zasobu, a nie systemu który go montuje)
W windowsie w "moim komputerze" można również użyć opcji "wysuń" na ikonce z partycją pendrive'a, czyli to takie windowsowe odmontowywanie. Używając metody "bezpieczne usuwanie" często rozłączało mi neo (aż dziwne), stąd akurat za tą opcją nie przepadałem.
Z Windowsowych głupot to pamiętam że w Win98 po bezpiecznym usuwaniu pojawiał się taki komunikat: "Sprzęt nie może być bezpiecznie usunięty". I w sumie była to racja, bo po ponownym podłączeniu pendrive windows zaliczał BSOD. Widocznie zapomnieli o "bezpiecznym wsuwaniu".
A Ty jesteś pewien, że nie uciekałeś ze szkoły, kiedy większość ludzi uczyła się czytać ze zrozumieniem?
Gdzie ja coś takiego napisałem, że KDE jest winne? Ja napisałem, że w opisie błędu na trackerze pojawiła się informacja, że pliki zostały zgubione, gdy KDE zawiesiło się tuż po starcie. Czyli w języku łopatologicznym: opisałem sytuację, gdy ktoś zauważył problem – nie jego przyczynę.
Równie dobrze zawiesić mogło się GNOME, ale tak się składa, że osoba, której się to przytrafiło, miała akurat KDE i że to KDE akurat grzebało w plikach konfiguracyjnych – tych samych, które system plików nie zdążył zaalokować przed zawieszeniem systemu. KDE widać robi też więcej drobnych operacji na małych plikach, więc w przypadku tego środowiska problem jest bardziej widoczny. I tylko tyle – nic o tym, że KDE jest winne.
/Jesli bys sie przylozyl to bys pominal to KDE4 – tylko przeszedl bys do sedna/
W sumie to EOT.
Kolejny newsman po szkole medialnej ojca dyrektora (z Torunia).
Ale ten raport naprawdę opisuje utratę plików konfiguracyjnych "(…)w sytuacji, gdy KDE 4 zawiesi się tuż po starcie systemu"
I z tym ojcem dyrektorem, to mocno przesadziłeś, bo ja tu widzę jedną osobą, która szuka ataków tam, gzie ich nie ma.
Nie ma to jak fanboye
A tak przy okazji, to nie zauważyłeś chyba, że na tej stronie rządzi Ojciec Dyrektor
Dla mnie to koniec tej bezsensownej dyskusji o niczym.
Zamiast pisac o KDE4 – autor mógł po prostu doczytac i napisac choc by o roznicy miedzy ext3 a ext4. Oba systemy posiadaja ta wade – choc w przypadku ext3 prawdopodobienstwo awari" jest mniejsze.
Przepraszam – nie chcialem Autora urazic ( ale sam tez pojechal)
@mith – jesli chcesz to Cie podszkole na wiosle (bo sam sie przyznajesz ze kaleczysz)
Edit: Głuszcu – nie nazywaj mnie fanbojem.
Poskiluj pisanie newsow. Cos przeczytales, uslyszales o wadzie ext4 ale nie wiesz w ktorym kosciele dzwoni.
Z blogu Ts'o:
Jeśli się z kimś dalej potrzebujesz kłócić, to odsyłam do niego. Mnie naprawdę szkoda nerwów…
Ale to wina kde4 ze czyta i zapisuje pliki konfiguracyjne, zamiast tylko czytać. Inaczej problem by nie zaistniał
Skoro są to po co zapisywać? Dla pewności?
sytuacja jest szczególna gdyż dotyczy a) zawieszonego systemu, b) który nie zaalokował jeszcze danych i b)jednocześnie otwiera dużą liczbę niezapisanych plików. Częściowo to wina kde, bo używa starych nawyków programistycznych, nieprzystających do nowych czasów, częściowo jądra bo się zawiesiło.
Tak samo jak na Windows.
nie przypominaj mi awarii zasilania podczas wyłączania windowsa… już nie wstał, co to za ficzer zapisujący ustawienia podczas wyłączania systemu
taaa, to wiele wyjasnia…
Ejże, to przecież wina planisty I/O a nie ext(3/4). I znowu ludzie od jajka przekombinowali…
Nie, to nie wina planisty I/O. Utrata danych spowodowana jest tym że system plików zleca zapis z opóźnieniem – planista nic do tego nie ma, bo jego robota zaczyna się dopiero jak system plików zechce zapisać te dane.
Winą są ludzie którzy nie robią fsync kiedy należy w swoich programach.
Warto dodać, że utrata danych może zdarzyć się również w przypadku nagłego zaniku zasilania, gdy dane nie zostały jeszcze zapisane na dysku. Jest to też możliwe.
Oczywiście masz rację. Utrata danych może zdarzyć się w każdej sytuacji, gdy komputer padnie przed zrzuceniem danych na nośnik.
Nie można po zawieszeniu wywołać synchronizacji danych przyciskiem SysRq?
Jeśli jeszcze działa to można.
"Zapodaj", jak konkretnie to się robi (nigdy nie potrzebowałem, ale a nuż…).
Alt+SysRq(PrtSc)+S
http://en.wikipedia.org/wiki/Magic_SysRq_key
RTFM MagicSysRq
Znacznie lepszą kombinacją od Alt+SysRq+S jest Alt+SysRq+U, ponieważ oprócz zrzucenia danych na dysk, partycje są odmontowywane i montowane w trybie tylko do odczytu, dzięki czemu po restarcie nie ma potrzeby sprawdzania systemu plików i odtwarzania dziennika.
Dzięki, takie rzeczy warto wiedzieć
Znacznie lepiej jest zrobic Sync a potem Umount
(w cytowanym arcie w Wikipedii jest REISUB albo RSEIUB jako pelna sekwencja)
Dla mnie najlepsza kombinacja to: Alt+SysRq i kolejno R E I S U B
Ja zazwyczaj resetuję przez S U B
Kiedyś w czytelni ubuntu był artykuł na ten temat. Aby zapamiętać sekwencje, podano takie zdanie: "Rybak Edward Idzie Spożyć Ulubiony Browar"
Ja wpierw próbuje sysrq+k (ubija wszystko na aktywnym vt) ale jeżeli to zawodzi to sysrq+s,u,b
Tak swoją drogą – Ubuntu 9.04 na serio ma wyjść z 2.6.29? (biorąc pod uwagę to http://www.phoronix.com/scan.php?page=news_item&a… )
jak na razie ma 2.6.28.9, więc wątpię
Czytając to zdanie jestem dumny że mam linuksa:D
A UPS-a masz?
niby nie zdaza sie na codzien – a osobiscie doswiadczylem takiej utraty plikow konfiguracyjnych kde4 kilka razy w ciagu 2 dni.
System sie nie powiesil – ale sterownik intela owszem, co uniemozliwilo normalny reset systemu (klawiatura i mysz przestawaly dzialac)
Po takim przymusowym uzyciu przycisku power musialem na nowo konfigurowac kde4. Kolejna systuacja pojawila sie przy uruchamianiu yofrankie – gry wykorzysujacej blendera. Przez przypadek nie wylaczylem opcji cieniowania w ustawieniach grafiki i znow system sie powiesil, kolejny raz czekala mnie konfiguracja kde4.
Problem rozwiazalem dodajac flage sync do opcji montowania systemu plikow. Oczywiscie nie winie za to programistow kernela – jakos trudno mi zaufac programistom kde4, ktorzy w trakcie zwyklego dzialania systemu pozostawiaja pliki konfiguracyjne otwarte.
Rozumiem taki zabieg w trakcie ich zapisu – ale to juz przesada by tak bylo caly czas.
Bo oczywiście zawieszanie sterownika grafiki NIKOMU w niczym nie przeszkadza. to wina KDE.
Windows nigdy mi się tak często nie zawieszał co linuks. Nawet nie chodzi o samo jądro które jest nawet stabilne w linuksie, ale wystarczy, że Xy które są znacznie mniej stabilne się zawieszą i nie można już nic zrobić, bo klawiatura i mysz nie pracują.
Sprawdziłem przed chwilą na na wirtualnej maszynie windowsa i linuksa. W windowsie zapisałem plik i w czasie jednej sekundy zrestartowałem maszynę. Efekt – plik został zapisany poprawnie. Analogicznie na linuksie z ext3, 2 sekundy po zapisie pliku i restarcie maszyny danych na dysku już nie było.
"Xy które są znacznie mniej stabilne się zawieszą i nie można już nic zrobić, bo klawiatura i mysz nie pracują."
Jeszcze nigdy (a wiele lat używam róznych linuksów) X-y nie zawiesily w taki sposób, żeby nie dało się przejść na konsolę tekstową np. przez Ctrl-Alt-F1 i stamtąd ubić sesji… Albo wprost Ctrl-Alt-Backspace i ubić całą sesję X-ów… Te kombinacje klawiszy obsługuje bezposrednio jądro więc nawet jak X-y wiszą to powinny one działać.
Chyba że mówisz nie o zawieszeniu X-ów, tylko o zawieszeniu *sterownika graficznego*, który – będąc częścią jądra – pociągnie za sobą jego resztę. Ale takiej wywałki – poza chyba jednym przypadkiem który miał miejsce przy *instalowaniu systemu* (kiedy to różnych niespodzianek można sie spodziewać
) – nigdy nie miałem…
A ja takie przypadki sporadycznie miałem za czasów XFree86, później za X11 było spokojnie, ale teraz mamy xorg i stało się to normą (zrypany sterownik Intela, tryb raw klawiatury, jakieś inne czary w okolicach hal).
FYI: ctrl-alt-backspace w X serwerze 1.6 jest domyślnie WYłączone, więc żebyś się nie zdziwił…
co do ZFS.. to on nie jest podatny ta takie awarie, gdyz tutaj dziala mechanizm copy-on-write, czyli albo wszystko jest zapisywane (plik zmieniany) albo nic, wiec nie maja prawa znikac pliki
Nie. Dokładniej przedział czasu w którym wyłączenie zasilania powoduje awarię może być krótszy. Czyli p-stwo mniejsze. Ale niezerowe.
Mylisz się. Poczytaj o działaniu copy-on-write w ZFS. Nawet gdy plik jesz zmieniany to fizycznie nie jest nadpisywany, ale kopiowany w inne miejsce, wiec jedyną konsekwencją awarii jak zanik zasilania/zwiecha jest to że plik pozostanie niezmieniony. Tak jak napisałem wyżej w ZFS nie maja prawa znikać pliki.
Nie mylę się. Następuje przepięcie metadanych które nie jest atomowe o ile nie masz dysku z podtrzymywaniem bateryjnym. To nie ma nic wspólnego z FS tylko z zasadą zapisu na dysk magnetyczny. Bo co się stanie kiedy zasilanie padnie gdy wskazanie na plik będzie właśnie zmieniane z jednej kopii do drugiej?
Przepisanie metadanych trwa nieporównanie krócej od zapisu danych. Uszkodzenia metadanych nie da się uniknąć w systemie bez nadmiarowości (raid 1, raidz) jednak prawdopodobieństwo uszkodzenia metadanych jest bliskie zeru właśnie przez ich niewielki rozmiar. Więc jest to całkowicie odmienna sytuacja od tej opisanej w artykule.
Brawo. Właśnie napisałeś to co ja dwie wiadomości wyżej. I po co się kłócić.
Metadane objęte są transakcją, więc w najgorszym wypadku takie 'przepięcie' pliku zostanie wykonane po raz drugi (przy odtwarzaniu dziennika).
Wniosek: stracić można co najwyżej zmiany (dokonane przed utworzeniem transakcji metadanych), ale nie cały plik i jest to niezależne od podtrzymywania samego nośnika. Zresztą podobne mechanizmy stosują bazy danych – odpowiada za nie literka 'D' w ACID, tyle że tam nie tylko metadane są zabezpieczane.
A tak na marginesie to ext3 w dzienniku ma nie tylko metadane, ale także dane w przypadku krótkich plików.
Reiser, reiser ma w dzienniku dane, ext3 nie wiem;)
1. w domyślnej konfiguracji ZFS w ogóle NIE POSIADA dziennika w tradycyjnej formie: nie dałby on w tej dziedzinie wiele więcej ponad to, co daje semantyka copy-on-write i end-to-end checksumming
2. linuksiarze mogą zaraz odpowiedzieć, że "ext4 jest szybszy"… i będą mieli rację, bo jest.
"A tak na marginesie to ext3 w dzienniku ma nie tylko metadane, ale także dane w przypadku krótkich plików."
Wydaje mi się, że jest trochę inaczej i akurat takiej sytuacji nie ma.
Domyślnie w ext3 ustawiony jest poziom "ordered", który oznacza, że w dzienniku są zapisywane tylko metadane, jednak dzięki powiązaniu zapisywania metadanych z danymi (dane zawsze zapisywane są na dysk PRZED zmianami opisujących je metadanych w dzienniku) szansa na uszkodzenie danych jest mniejsza niż w przypadku poziomu "writeback", gdzie akutalizacja danych w dzienniku może wyprzedzać zapis danych na dysk.
Jedynie w przypadku trzeciego poziomu księgowania "journal" do dziennika zapisywane są i metadane i dane.
Co ciekawe, choć teoretycznie tryb "journal" powinien być zawsze najmniej wydajny, to realnie jego włączenie potrafi niekiedy przyśpieszyć działanie systemu plików.
@bies: W wolnej chwili moglbys doczytac, jak dzialaja LFS-y w ogole i ZFS (tak, wiem ze jego tworcy zarzekaja sie, ze to nie jest log-structured filesystem. Moim zdaniem wciskaja kit.
w szczegolnosci.
@maciek: Bys sie zdziwil. ;->
Odnośnie szybkości? Nawet Sun potwierdza, że ZFS nie jest od linuksowego ext3 FS szybszy, a przynajmniej nie zawsze i nie w "prostych przykładach":
http://www.sun.com/storage/flash/performance.jsp
Ext4 nie sprawdzali, ale WEDŁUG PRZECHWAŁEK AUTORÓW ext4 ma być szybszy.
@maciek: Ale zdajesz sobie sprawe, ze podales linka porownujacego wydajnosc normalnych dyskow i SSD, a nie ZFS-a z czyms innym?
Tak, ZFS nie jest wydajniejszy we wszystkim. W wielu rzeczach jest wolniejszy. Ale w kilku bardzo istotnych jest szybszy, wiec stwierdzenie, ze "ogolnie jest wolniejszy" mija sie z prawda.
Zdaję sobie sprawę, czego to porównanie dotyczy.
I w nim są wyniki określające szybkość MySQL z dyskiem "zwykłym" i SSD dla linuxa i dla opensolarisa z ZFS. I zarówno z dyskiem zwykłym jak i ssd Linux wypada jako SZYBSZY od opensolarisa z ZFS.
Tak, ZFS był tworzony z myślą o szybkości, tak, ZFS jest znakomicie zoptymalizowany, ale nie, ZFS nie jest "ogólnie szybszy" od zwykłego systemu plików. I Tak, wiem, że ZFS to nie jest tylko system plików.
@mby7930 – no przecież po minucie napisałem, że chodziło mi o reisera. W dzienniku ext3 nie grzebałem, nigdy nie miałem potrzeby, ostatnie co odtwarzałem ręcznie to ext2 (szkoda, że nie istnieje odpowiednik lde dla reisera).
I chociaż nie mam czasu tego sprawdzać, to w ciemno mógłbym stwierdzić, że w przypadku ext3 będzie podobnie – księgowanie odbywa się na poziomie bloków, w takim razie dziennik powinien zawierać część danych zawartych w blokach z I-nodami pierwszego stopnia, a więc zawierać krótkie pliki także dla trybu ordered (czego w manie raczej nie znajdziesz).
A można będzie zablokować to zabezpieczenie? U mnie się nic nie wiesza, i nie mam ochoty spowalniać sobie maszyny – na moje własne ryzyko.
Wiem, że to by bardziej obciążyło procka – ale czy nie najlepszym wyjściem jest zapisywanie tych danych od razu do swapa, a z opóźnieniem na dysk?
Gdy wszystko się powiedzie, dane w swapie są po prostu ignorowane. Gdy system się zawiesi, podczas kolejnego fsck transakcje byłyby dokańczane ze swapa.
Procek będzie nieco bardziej zużyty, choć i tak marnuje się go dziś na mniej ważne sprawy niż bezpieczeństwo danych. Ale najważniejszy zysk, czyli brak fragmentacji zostanie zachowany. A jednocześnie dane będą bezpieczne.
Ewentualnie zamiast swapa może być jakaś specjalnie do tego celu wydzielona niewielka przestrzeń partycji ext4.
Procek to w tym wypadku jeszcze "małe miki"; istotniejsze jest wydłużenie czasu operacji dyskowych przy zapisie.
Cały zysk czasowy płynący z "delayed allocation" diabli by wzięli.
"It's not a Bug, it's a Feature"
Jeden artykuł i taka wojna ……… ehhh……..
Uzywam ReiserFS; warto sie przesiesc na Reiser4FS? Czy Reiser4FS jest juz w wersji finalnej?
> Uzywam ReiserFS;
OT
> warto sie przesiesc na Reiser4FS?
Podobno już to zrobiłeś
> Czy Reiser4FS jest juz w wersji finalnej?
Nie i raczej nigdy nie będzie
@Linuxiarz: Raiser4 nie będze ukończony bo jego autor do więzienia poszedł…
Poza tym u mnie na Arch linuxie domyślnie jest ustawiony dla ext4 time interval 5 sec i nie ma problemu (pokazuje to na starcie)
A mi z Archa konfigi poznikały, potem po kolejnym uruchomieniu nie było już ważnych plików systemowych, potem już się system nie uruchamiał. Te ext4 się do niczego nie nadaje.
Niestety, potwierdzam. U mnie wystąpił podobne problem. Świeżo postawiony i skonfigurowany Arch pracował do pierwszej aktualizacji. Po restarcie już nie wstał z błędami dysku. Próba naprawy sytemu plików nie przyniosła żadnych efektów. Aż się boję co będzie dalej bo mam już trzy maszyny z ext4…
Ten post to żadna rewelacja – opóźniony zapis czyli keszowanie zapisu – dokładnie taki sam problem był ze smartdrv pod DOSem.
Właśnie. Nie wiem po kiego licha taka awantura. Przecież to zawsze tak będzie działać jeśli jest cache.
Niech lepiej rozwiążą problem z pendrive w KDE4 – gdy się kopiuje jakieś dane (system plików FAT) to info o kopiowaniu szybko znika, dane jednak są dalej zapisywane. Troszkę za szybkie odmontowanie i mamy uszkodzony plik (którego nie można usunąć – tylko formatując pendrive)
Nie da się odmontować pendrive'a gdy plik jest w trakcie zapisywania. Albo wszystkie dane zostaną wypchnięte na dysk i dysk odmontowany, albo odmontowanie się nie powiedzie. To że KDE zamyka dialog nie oznacza, że dane zostały fizycznie zapisane na dysku, tylko że zostały przesłane i oczekują na zapisanie. A zapis zajdzie wtedy, gdy kernel o tym zadecyduje i KDE nie ma na to żadnego wpływu. Chyba że programiści celowo wymuszą flush danych przed zamknięciem dialogu, ale to pogorszy wydajność.
W jaki sposób flush pogorszy wydajność ?? I tak i tak dane muszą być zapisane na pendrive. Wydajność przecież nie będzie większa jeśli zniknie nam okienko dialogowe, a dane nadal będą zapisywane. Taki flush na końcu kopiowanych danych byłby bardzo przydatny. Albo w ogóle najlepiej by było gdyby dane na pendrive były zapisywane w czasie rzeczywistym, bo najczęściej po zapisie danych na pendrive i tak jest on odmontowywany.
Pogorszy, jeśli zapisywana jest duża liczba małych plików w krótkich odstępach czasu. Czas dostępu do pendrive jest wyższy niż do dysku twardego, a transfer dużo niższy. Więc wywoływanie co chwilę flush może spowodować, że system będzie skakał "żabką", w momentach gdy kernel będzie czekał na zakończenie i/o. Poza tym zapisywanie w czasie rzeczywistym może doprowadzić do szybszego zużycia pendrive ponieważ wymusi znacznie częstsze zapisywanie bloków, gdzie przechowywane są struktury FAT w celu zachowania spójności danych.
Wystarczy montować z opcją "sync", tyle że z moich doświadczeń chodzi pendrive wtedy bardzo wolno.
"gdy się kopiuje jakieś dane (system plików FAT) to info o kopiowaniu szybko znika, dane jednak są dalej zapisywane. Troszkę za szybkie odmontowanie i mamy uszkodzony plik (którego nie można usunąć – tylko formatując pendrive)"
Windowsy robią dokładnie tak samo… Moje dzieci bedąc nieświadomymi tego faktu (albo zapominając, jak już im o tym powiedziałem) już tyle razy spieprzyły sobie odtwarzacze MP3…
bo dymek znika jak dane trafią do bufora, a nie jak trafią na pendrive, np taki system powinien w teorii wydłużyć czas pracy na baterii. Dysk jest szybszy od pendriva, więc zamiast czekać, aż ten wolny pendrive zapsize dane, dysk szybko przerzuci dane do bufora w pamięci operacyjnej, a z tamtąd już spokojnie trafiają na pendrive. Oczywiście nie jest tak, że pendrive czeka aż bufor się zapełni, cała sprawa dzieje się w tym samym czasie, po prostu to co nie zdąży trafić na pena trafia do bufora, a następnie na pena.
U mnie pokazuje się ikonka z "i". Proces kopiowania można zobaczyć klikając na tą ikonkę.
Bo się nie patrzy na kreatorki, tylko na diodkę – nigdy nie kłamie.
o ile mi wiadomo na dole w trayu chowa sie notyfikator do podgladu postepu ale fakt monit znika zbyt szybko
No z ext4 szału nie ma, ja rozumiem utrafic nie zapisane dane, ale zeby wywalalo mi cala zawartosc pliku, zamiast po prostu nie dopisac do niego zmian? Teraz juz wiem dlaczego gdy uzywalem ext4 i pare razy padlo mi zasilanie, stracilem cala zawartosc .zsh_history zarowno usera jak i roota, gdzie owe pliki byly na oddzielnych partycjach ext4. Dobrze, ze reiserfs nie ma takich zonkow, nigdy nic nie zgubil mi.
Reiserfs jest bardzo dobry – coś 8 lat go używałem (kończąc na 3.6.25), zanim ostatnio przesiadłem się na ext4, ale jednak zauważam widoczne, nie iluzoryczne, pozytywy tej decyzji:
- fsck kończy robotę znacznie szybciej
- głowica dysku – jak na moje ucho – "chodzi" znacznie mniej (to się słyszy szczególnie orzy starcie systemu). Nie grzechocze aż tak, jak to było w przypadku reisera
- czytanie zawartości katalogu z dużą ilością plików (np. ze 2 tysiące) trwa znacznie szybciej, niż w przypadku reisera (widać to np. wtedy, gdy uruchamia się mc – jest szybciej gotowy do pracy)
Nie przeprowadzałem żadnych "benchmarków" i pomiarów, bo dla mnie istotny jest "overall feeling" – a więc, czy to "widać, słychać i czuć". Jeśli miałbym dopiero samymi pomiarami przekonywać się, że "jest lepiej", to taka kosmetyczna "poprawa" nie miałaby dla mnie znaczenia.
Ext4 mial buga, nie wiem czy ma go nadal, ze gdy odpaliles firefoksa i mieliles ostro na plikach, np. kopiowales 60GB danych, ext4 mial hardlocka, coś takiego: https://lists.linux-foundation.org/pipermail/bugm….
Pozatym czesto po resecie mialem "no space left' mimo, iz mialem lekko 63% wolnego miejsca, automagiczny fsck wywolywany przez fstab twierdzil ze system czysty, jedyne co pomagalo to wymuszony, pleny fsck. Extowi czwartemu jeszcze duzo brakuje.
> Ext4 mial buga, nie wiem czy ma go nadal
Widocznie już nie – bo "requested URL not found".
> Pozatym czesto po resecie mialem “no space left’ mimo, iz
> mialem lekko 63% wolnego miejsca
To się zgadza; raz zrobiłem – w celach czysto testowych – "brutalny reset", i sam stwierdziłem coś takiego. Ale to może być chyba celowo(?) – znaczy: zmuszenie użytkownika do fsck, żeby nie nadpisał danych (przynajmniej ja to tak wtedy widziałem).
> automagiczny fsck wywolywany przez fstab twierdzil ze system
> czysty, jedyne co pomagalo to wymuszony, pleny fsck
Też widzę coś takiego, że fsck wywoływany z initrd.img jakoś po prostu… nie jest wykonywany. Za każdym razem stwierdza, że "clean", i odpuszcza sobie robotę.
Moja wina, wywal kropke po html to juz nie bedzie, ze nie ma. http://bugzilla.kernel.org/show_bug.cgi?id=12679 tutaj sensowniejszy link do buga.
A problem nie był w tym, że skończyły się inody? Bo ja tak miałem, że na ext4 miałem masę drobnych plików (źródeł OpenOffice, Firefox i chyba całe KDE4
) i w pewnym momencie zacząłem dostawać błędy "No space left on device". <code>df</code> pokazał 30% wolnego miejsca, ale <code>df -i </code> pokazał 0 wolnych inode. Trzeba było przeformatować partycję. 
Nie, nie bylo problemu z brakiem wolnych inodes.
A ten reiser Ci się nie sfragmentował przypadkiem?
Hmm jak dla mnie dziwne tłumaczenie developerów ext4 i zwalanie na twórców aplikacji. Rozumiem że przez to że zapis jest opóźniony przy zawieszeniu systemu niektóre pliki się nie zapiszą i pozostaną w starych wersjach, ale żeby były czyszczone? Dlaczego operacja truncate (również gdy otworzy się plik od razu z opcją truncate) i zapis do pliku nowych danych nie są wykonywane zaraz po sobie przy kolejnym zapisie na dysk (po owych 45-150 sekundach)? Wtedy szansa na wyzerowanie pliku byłaby dużo mniejsza (choć zawsze istnieje), a teraz jest ogromna..
Zawsze komputer może przestać działać, nawet jeśli nie z powodu błędu z oprogramowaniem to ze sprzętem czy zasilaniem. Systemy plików powinny być tak pisane żeby szkody w tym przypadku były możliwie jak najmniejsze.
Rozumiem że deweloperzy aplikacji wykorzystują interfejs trochę źle i powinni zrzucać ważne dane natychmiast w wypadku gdy czyszczą plik, albo zapisywać nowy plik pod nową nazwą i przenosić go w miejsce starego. Robią to z tego powodu że nie mają wpływu na jakim systemie plików będzie operować aplikacja i nie chcą tracić wydajności na innych bardziej popularnych systemach plików. Bardzo ciężko będzie poprawić cały kod aplikacji – lepiej trochę przystosować ext4 do realiów (zresztą nie widzę dlaczego miałaby na tym ucierpieć wydajność – wyzerowanie dopiero w momencie zapisu).
Bo ext4 jest zaburaczony jak mało co i nie powinien nigdy się ukazać jako 'stabilny'.
Dostał się do mainline chyba tylko dzięki nazwie i kompatybilności wstecz z działającym dobrze ext3.
Jeden z developerów Gentoo (Betelgeuse), jak pisał alternatywny backend dla metadanych dla Portage (używający xattr) wykrył przypadkiem błąd w obsłudze extended attributes w ext4. Przy używaniu xattr i ext4 miejsce na dysku kończy się w zastraszającym tempie – oczywiście df/du nie biorą pod uwagę miejsca zajmowanego przez xattr przy raportowaniu ilości wolnego miejsca na dysku – stąd wykrycie takich problemów jest utrudnione.
W jaki sposób kernel miałby sztucznie utrzymywać plik otwarty z O_TRUNC w stanie "nie-uciętym"? Błąd wynika z tego, że aplikacja otwiera plik z tą flagą, a następnie długo trzyma plik nie zapisując nic do niego. Ucięcie pliku następuje przy początkowym flushu, a że później nic się z tym plikiem nie dzieje to już chyba wina aplikacji.
Masz racje jeśli długo trzymają otwarte i nic nie piszą albo piszą tylko część. Ale mi się wydaje że cała operacja trwa dość szybko (mniej niż 45 sekund), otwierają plik i piszą coś do niego i go zamykają, natomiast plik jest obcinany w momencie otwarcia (ponieważ jest ustawiona ta flaga) ale zapis do pliku następuje dopiero po 45-150 sekundach. Jeśli aplikacje faktycznie otwierałyby tak pliki i długo nie pisały nic do nich to ten sam problem występował by w ext3 bo na początku plik by był czyszczony i jeśli aplikacja czekałaby długo z zapisem (dłużej niż 5 sekund), a system się zawiesił plik pozostawał by pusty. Dlaczego nie czyścić pliku dopiero przed zapisaniem czegoś do niego w jednym okresowym zapisie do dysku po owych 45 sekundach?
Obecny patch robi to tak że po 5 sekundach zrzuca na dysk pliki otwarte z O_TRUNC (jeśli dobrze zrozumiałem) – czyli też musi sztucznie przechowywać o nich informacje. A w jaki sposób kernel miałby to robić? Nie widze problemu dlaczego system plików nie może tak działać.. (mogę się mylić, nie znam się na tym).
Faktycznie jest tak jak mówisz. Jeśli dobrze rozumiem to w jądrze 2.6.30 powinny znaleźć się poprawki od Teda Ts'o, które gdy wykryją, że plik został otwarty z O_TRUNC, to po zamknięciu pliku zostanie wymuszone zapisanie danych na dysku, razem z metadanymi w dzienniku.
Nie. Błąd wynika, z tego, że aplikacja robi:
open(plik, O_TRUNC);
write(plik, …);
close(plik);
ext4 najpierw obcina plik (open()), a dane z write() zapisuje z dużym opóźnieniem. Jeśli system padnie miedzy jednym a drugim, to zostajemy z obciętym plikiem. ext3 ma ten sam problem, tylko że tam opóźnienie było mniejsze (5s vs. 140s). Opóźnienie wprowadza sterownik ext4, a nie aplikacja!
Oczywiście zgodnie z POSIX system _może_ w takiej sytuacji obciąć plik (i w tym sensie autorzy ext4 mają rację, że wina leży po stronie twórców aplikacji). Natomiast wcale nie oznacza to, że system plików _powinien_ się tak zachowywać. Inaczej mówiąc, należy oczekiwać, że w typowych przypadkach użycia system zachowa się prawidłowo, nawet jeśli nie jest to formalnie zgodne ze standardem.
Ubuntu 9.04 nie bedzie wydane z kernelem w wersji 2.6.29.
http://www.heise-online.pl/open/Ubuntu-9-04-nie-b…
@Mith
Znowu dzwonia – ale w ktorym kosciele?
Co to jest vaniliowy kernel?
to jest taki, jaki ściągasz z kernel.org (bez "obcych" łat)
Smaczny kernel
A ja wole z przyprawami (tuxonice) i w ładnym opakowaniu (fbcondecor)
Wiem, że Reiser siedzi w wiezieniu, ale przeciez on w pojedynke systemu plikow nie pisał; bodajze tworzyla ten FS firma nemezis.
Kto ma teraz prawa do FS Reiser?
Bo jesli jest ten FS "otwart" to dzielo moze dokonczyl spolecznosc…
Nie nemezis a namesys, reiserfs i reiser4 sa otwarte.
To tak jak w Windows XP, tylko tam jest taka sytuacja, że jak podczas zamykania systemu wyłączą prąd, wtedy system już nie zadziała. Nie wiem czy zawsze tak jest, bo możliwe, że trzeba w odpowiednim momencie wyciągnąć wtyczkę, jak zapis wykonuje do danego pliku, który takie uszkodzenie tworzy.
Myślę, że jest to raczej kwestia uszkodzenia plików takich jak bitmapa lub dziennik, krytycznych do obsługo systemu plików. Miałem kiedyś taką sytuację, że po BSOD błędy na dysku były tak poważne, że chkdsk nie mógł dać im rady i sam się wywalał nawet jak uruchamiałem go z płyty ratunkowej. Pomogło dopiero wyzerowanie dziennika przy pomocy ntfsprogs. Dobrze, że można liczyć na niezawodne opensource'owe projekty! Miękki pewnie radziłby usunięcie partycji i format.