Linux – u mnie działa! – Nowoczesne systemy plików
- Dodano: 16 marca 2009
- Wprowadził: Kamil Reszczyk
- Komentarze: 65
Po dwóch latach przerwy, Koło Naukowe Informatyków „Kernel” zaprasza na reaktywowaną serię wykładów „Linux – u mnie działa!”.
Abstrakt wykładu:
Wzrost pojemności dysków twardych oraz pojawienie się w ostatnim czasie napędów typu SSD wymaga zmiany podejścia do składowania danych. Przekłada się to bezpośrednio na systemy plików używane na serwerach i stacjach roboczych, ale także na technologie zabezpieczeń przed awarią. Duża dynamika wspomnianych zmian wymaga zmiany podejścia do składowania danych. Marek Magryś omówi problemy przed jakimi stają użytkownicy współczesnych dysków twardych oraz nowoczesne systemy plików i systemy składowania danych, które pomagają lepiej użytkować współczesne dyski twarde oraz wprowadzają nowe, przydatne funkcjonalności. Prelegent postara się także określić, co będzie się działo w najbliższych latach w kwestii technologii dyskowych.
Miejsce: Wydział Fizyki i Informatyki Stosowanej AGH, (D10), Kraków
Czas: czwartek 19 marca 2009, godz. 18:00
Sala: A
Więcej informacji: http://lumd.linux.pl
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.
65 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
Nie wiem czy to dobry temat po bugu 'z ext4'…
bug w ext4 zostanie poprawiony, a poza tym jest om niemożliwy gdyby był UPS. UPS zaś jest zaś niezbędny gdy są skoki napięć, a nawet zawsze. Jeśli nie wiecie: listwa przepięciowa nie ochroni przed skokiem napięć a UPS tak (zostało potwierdzone w życiu).
System plików, który się chrzani "bo nie było UPS"… to system plików źle zaprojektowany.
@dinth: a jest cos w ogole takiego jak 'najnormalniejszy' pad systemu? moze jestem nienormalny, z krotko bylem w wojsku…, ale mi linux w ciagu ostatnich 9 lat padl moze z 5 razy
Zalezy co z nim robisz. Jesli dziala on jako przegladarka do internetu i nic nie zmieniasz to bedzie dzialal, lecz jesli lubisz testowac rozne eksperymentalne wersje, to reinstalki beda zdarzac sie o wiele czesciej.
Och! Ale życie by było proste! Najlepiej od razu – nie naciskaj "save", jeśli nie zapłaciłeś elektrowni za prąd.
Czy najnormalniejsze zwiechy systemu rowniez wytlumaczysz brakiem UPSa ?:)
Bug mnie dosiegnal gdy probowalem zmienic fglrx na radeonhd-r600-r700-git. Wygladalo to tak: modyfikacja xorg.conf, reset systemu, crash przy ladowaniu Xow, reset systemu w single-mode, _pisanie_z_palca_ nowego xorg.conf z nowymi ustawieniami, uruchomienie Xow, crash, reset systemu w single-mode, _pisanie_z_palca_ nowego xorg.conf i tak w kolko.
Ja używam pewnego ważnego dla mnie programu, który zapisuje plik z danymi co 5 sekund, właśnie po to, aby nie stracić ważnych danych w przypadku awarii. Póki używałem ext3 wszystko było w porządku, ale po przejściu na ext4 dane tego programu były zawsze tracone po crashu systemu. Dziwne, że dopiero teraz odkryto ten bug i nikt nie zwracał na to wcześniej uwagi.
U mnie wszystko ok mimo, że po update Ubu 9.04 system nie reagował i dostał twardy reset (power w laptopie). A dziś podczas aktualizacji padła bateria i skończyło się tylko na zepsutym jednym pakiecie. Dwa komputery mam postawione na Ubu 9.04 + Ext4 i jest OK
@aix: słuchaj, to że ty nie rozumiesz jak działa lista przepięciowa nie oznacza, że masz się tym chwalić i siać dezinformację. Listwa (typowa) zabezpiecza właśnie Tylko przed skokami napięcia. Niektóre modele mają jeszcze dodatkowe filtry i wyłączniki nadprądowe. Te lepsze potrafią nawet zareagować na niewielkie spadki.
> Listwa (typowa) zabezpiecza właśnie Tylko przed skokami napięcia.
Tyle, ze Tobie tylko chodzi o skok w gore, a po drugie zabezpieczenie rozumiesz (zapewne) przez odciecie pradu. To zadne wiec zabezpieczenie tak naprawde.
@macias: kurcze jak ja nie lubię fanów szybkich odpowiedzi na pałę- a wiesz co to jest PRZEPIĘCIE? Wobec czego można oczekiwać po listwie przepięciowej (poprawniej pewnie zwanej przeciwprzepięciowej)- ano że zabezpieczy przed przepięciem- czyli wyobraź sobie skokiem napięcia w GÓRĘ- jak mówi definicja. O tym co potrafią takie napięcia porobić w PC można długo, ale po co.
Odpowiem jeszcze na jedno- nie, nie odcina wyobraź sobie prądu (o ile rozumiesz czym jest prąd a czym napięcie), bo nie wiem czy rozumiesz (a zakładam, że nie masz bladego pojęcia), że można manipulować napięciem w inny sposób niż włączanie i wyłączanie.
Na koniec- poczytaj wiki chociaż o tym czego nie pojmujesz a swoje własne przemyślenia oznaczaj, że to własne przemyślenia, bo potem ktoś cię zacznie cytować i urośnie nam kolejne pokolenie niedoinformowanych pseudo ekspertów walących podobne frazesy.
@macias: najpierw poucz się trochę elektroniki, a potem zabieraj głos. Zapewne o takim wynalazku jak stabilizator to jeszcze nie słyszałeś. Poszukaj info o diodzie Zenera. Masz najprostszy przykład stabilizatora.
A ja mam skoki libido – ochroni mnie listwa wtedy?
jakim bugu? to już było powiedziane wcześniej to nie bug tylko przyszłość i gdyby programiści aplikacji przy ważnych danych wymuszali natychmiastowy zapis na dysk to nie było by problemu…
Wiem ze to offtopic.
Ale w jaki sposób mają to wymuszać? Jest to odwołanie się do funkcji systemu plików, czy jakoś inaczej?
A poza tym: czy system plików nie powinien być transparentny dla aplikacji? Jako programistę aplikacji nie interesuje mnie, czy FS zapisuje dane bajt po bajcie, czy może trzyma kilkadziesiąt megabajtów w pamięci, zanim je zapisze. To "prywatna" sprawa systemu plików.
Po trzecie: co to są "ważne dane"? To znaczy, że transakcje bazodanowe mają być zapisywane na dysk od razu, ale ściągnięty plik mp3 może już się uszkodzić? Bo przecież jest "nie ważny"? Ja zakładam, że wszystkie dane są dla mnie ważne. I nie chcę ich stracić, a na pewno nie całkowicie (starą i nową wersję). Więc musiałbym mieć cały natychmiastowy zapis.
Dlaczego nie rozwiązać tego poprzez nie nadpisywanie starych danych do czasu wpisania nowych? Potem przeadresowanie inodów jest już na tyle krótkie, że nowsze dyski wykonają jeszcze te operacje w całości.
Żeby nie było: używam ext3 i bardzo podoba mi się ten FS. Ale albo ja czegoś nie rozumiem w tym problemie, albo błąd jest tylko i wyłącznie w systemie plików, a wina zwalana jest bezpodstawnie na twórców aplikacji.
Wystarczy użyć jednej flagi przy pisaniu do pliku. Tak, to nie jest lenistwo programistów, wcale
o bożek… i znów o "bugu w ext4"…
ludzie! problem w tym, ze to nie jest bug ext4!
standard POSIX jasno stwierdza, że w przypadku nagłego padu systemu zachowanie systemu plików jest "undefined" – niezdefiniowane, nieprzewidywalne.
developerzy przyzwyczaili się do domyślnego 5s "okienka commitów" na ext3 i zaczęli pisać kod nie biorący pod uwagę, że okienko może być szersze – jak domyślne 60s w ext4 (w ext3 też można ustawić szersze zresztą). zamiast pisać kod porządny, wywołujący fsync() gdy jest krytycznie ważne, by dane *na pewno* trafiły na dysk od razu, opierali się na de facto przypadkowej cesze domyślnych ustawień ext3.
a teraz ludzie płaczą, ze im "ext4 zjadł pliki". nie, nie ext4, a niezgodna ze specyfikacją obsługa systemu plików w programach.
poza tym, zamiast tysięcy małych, wciąż nadpisywanych plików (co aż prosi się o fuckup przy padzie napięcia czy systemu), należałoby może zacząć używać rozwiązań przemyślanych i stworzonych właśnie do tego typu zastosowań? jak sqlite, nudge nudge wink wink? jak to firefox robi?..
eś, "bug w ext4", jak zaraz mnie coś nie trafi…
"a teraz ludzie płaczą, ze im “ext4 zjadł pliki”. nie, nie ext4, a niezgodna ze specyfikacją obsługa systemu plików w programach."
We wszystkich systemach jakie znam fclose zapisuje plik, jeśli dane po tym się nie zapiszą to na pewno nie jest to wina programisty.
> "We wszystkich systemach jakie znam fclose zapisuje plik"
A miliony much g_wno żre.
POSIX jasno definiuje co się dzieje po fclose.
Doczytaj i przeproś za swoją niekompetencję.
polecam:
http://thunk.org/tytso/blog/2009/03/12/delayed-al…
i
http://thunk.org/tytso/blog/2009/03/15/dont-fear-…
fclose() nie wywołuje samo z siebie fsync(). to oznacza, że jeżeli programista chce obejść ustawione okienko commitowania i mieć *pewność*, że dane są na magnetycznych talerzach dysku, a nie w cache'u takim czy innym, *musi* użyć dodatkowo fsync(). koniec i kropka.
jak się nie podoba, proponuję przepisać standard POSIX.
ale, jeżeli fclose() będzie miał wywoływać fsync() domyślnie, szybkość systemu plików (i całego systemu) spadnie dramatycznie (zapisy do cache'u/RAMu są kilka rzędów wielkości szybsze, niż na dysk twardy, nawet SSD).
dodajmy, że ten "bug" dotyczy wszystkich systemów plików z opóźnioną alokacją, czyli… wszystkich nowoczesnych systemów plików.
@MichalK: a guzik prawda. fclose() nie zapisuje pliku ani w ext3, ani w xfs (i chyba w reiserfs też nie).
@MichalK @AdeBe
w zadnym nie zapisuje bo jej zachowanie nie zalezy od systemu plikow. fclose() wola fflush(), ktora powoduje oproznienie buforow udostepnianych przez biblioteke standardowa i nijak ma sie do uzytego systemu plikow.
No to powiem wam ze mnie zaskoczyliscie, widoczne w tym systemie jest inaczej niz wszedzie.
Czy to wada czy zaleta zostawiam kazdemu do przemyslenia.
@rysiek z dedykacja:)
"Dear filesystem writers – application developers like writing lots of tiny files, because it makes a large number of things significantly easier. This is fine because sheer filesystem performance is not high on the list of priorities of a typical application developer. The answer is not "Oh, you should all use sqlite". If the only effective way to use your filesystem is to use a database instead, then that indicates that you have not written a filesystem that is useful to typical application developers who enjoy storing things in files rather than binary blobs that end up with an entirely different set of pathological behaviours. If I wanted all my data to be in oracle then I wouldn't need a fucking filesystem in the first place, would I?"
http://mjg59.livejournal.com/108257.html
swoja droga polecany przez Ciebie fsync() nie rozwiazuje problemu, a jedynie zmniejsza okno czasowe mozliwego wystapienia bledu. nie masz zadnej gwarancji, ze w momencie powrotu z fsync() dane faktycznie zostaly zapisane na nosniku fizycznym (np. z powodu wlaczonego write cache).
to co powoduje, ze ludzie narzekaja na ext4 (a nie przeszkadzalo im to np. w ext3) jest to, ze w przypadku padu systemu, widocznym efektem na ext4 jest 'zgubienie' pliku przez fs, co w podobnej sytuacji np. z ext3 wiazalo sie "tylko" z bledna(starą) zawartoscia pliku. zachowanie ext4 jest po prostu bardziej uciazliwe dla uzytkownika.
sqlite? Znaczy się baza danych? Masz na myśli coś takiego dla systemu czy tylko dla poszczególnych programów? Zresztą nie istotne… M$ wprowadził to na szerszą skalę bodaj w Win95 i od tego czasu 'coś w Windows nie działa? Reinstalacja…'
Właśnie dzięki tysiącom małych plików nie mam problemu z ratowaniem systemu, gdy coś się schrzani…
coś w tym jest… tylko widzisz, nawet jakby używano sqlite, to wiadomo by było, że używane jest sqlite i każdym klientem sqlite mógłbyś to odczytać/zmienić/zapisać przy walce z nie bootującym systemem.
do plików tekstowych też musisz mieć edytor tekstu. i tak samo jak edytor tekstu, narzędzia do sqlite są dostępne w każdym distro, na sporej ilości live-cd.
w przypadku microszitu, nie wiadomo co to; nie wiadomo, jak to zjeść; narzędzi nie ma. tu sytuacja byłaby nadal diametralnie różna.
i nie rozmawiamy to o plikach konfiguracyjnych gruba czy /etc/fstab, tylko o setkach małych plików tworzonych/nadpisywanych w sesji KDE/GNOME. przyznaj się, co robisz gdy poważnie skopiesz ustawienia KDE? szukasz konkretnego z tysiecy plików? czy wywalasz całe .kde i zaczynasz od zera.
Nie jestem ekspertem w dziedzinie fs-ów, ale czy nie właśnie księgowanie i FS-y z nim, miały być absolutnym lekarstwem na wyżej opisywane problemy ?
Bo tego co wiem, to właśnie miała być podstawowa a może i jedyna zaleta tego kięgowania.
Z waszych wypowiedzi wynika że dla zwiększenia wydajności, tak naprawdę je całkowicie zniesiono i mamy obecnie tylko wirtualne księgowanie .
Patrze w man 2 fsync i co widze?
Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
To mi przypomina patcha dirsync na qmaila, ktory dodawal sync na katalogu danego pliku.
Tak czy owak, po lekturze fclose, fflush i fsync wyglada na to, ze fflush() wysle dane po stronie userspace. Kernelspace nadal moze je przetrzymac i wtedy fsync(), fdatasync() trzeba.
A moze nawet fsync() na katalogu (ale kto tak robi naprawde?)
Zatem jak mam robic ?
1. Gdy zamykam plik fclose() – mam po tym robic fsync() i fsync() na katalogu?
2. Gdy jestem w trakcie zapisywania i wlasnie zrobilem fwrite to powinienem fflush() a potem fdatasync() ?
@Pysiak:
nic nie mozesz zrobic (z man fsync):
"In case the hard disk has write cache enabled, the data may not really be on permanent storage when fsync/fdata-sync return."
i problemem nie musi byc tylko write-cache na dysku ale rowniez np bufory w kontrolerze raid itd..
@janc: O, kolejne miejsce, gdzie Linux dosyc mocno rozmija sie ze standardem – ktory, iirc, wyraznie mowi, ze po fsync(2) dane maja byc na stable storage. Czyli na dysku albo podtrzymywanym bateryjnie cache'u kontrolera.
"ludzie! problem w tym, ze to nie jest bug ext4!"
Dlatego dałem w czudzysłowie. I przyimek 'z' a nie 'w' (a właściwie 'w implementacji') czy brak 'bug ext4'.
Takie skojarzenie – 'system plików' i 'działa' – jak widać ludzie potraktowali to mniej w kategorii żartu niż ja.
Kto będzie prelegentem wykładu?
"Marek Magryś omówi problemy…" Mozna bylo przeczytac newsa, ale to pewnie bylo zbyt trywialne…
Mój błąd, przepraszam
Witamy w Aborygenii — wyklad bedzie abstrakcyjny o ekologii, uczestnicy dowiedza sie recyklingu i utylizacji odpadow komputerowych. _Streszczenie_ i _wykorzystanie_. No chyba, ze prelegentem bedzie osobnik z dzida wykladajacy, ze bialy buana lubic komputer zwlaszcza jak miec SSD.
Uprasza sie o minimum szacunku do Czytelnikow LN.
Eee… a jakby tak trochę jaśniej? Coś słaby dzień mam i nie rozumiem, co Ci się nie podoba.
dołączam się do pytania
Maciasowi chodzi o słówko "abstrakt" zamiast bardziej polskiego "streszczenie". Ale słówko "abstrakt" i tak mi się wydaje bardziej zrozumiałe od jego posta ;-P (chociaż faktycznie rzuca się w oczy…)
watpie zeby o to chodzilo.
Raczej o to, ze nie wiadomo o co chodzi.
Po przeczytaniu tego newsa naprawde nie wiem o czym on bedzie mowil.
Sciągnąłem wersję LiveDVD i nie mogę wejść do systemu, twierdzi, że zły login. Pomimo, iż wppisuje te dane, które są przy pobieraniu (login/hasło) 3h ściągania i gó**o…
Przepraszam zagalopowałem się i nie w tym newsie, co trzeba napisałem
Pozdrawiam Asasello
Gdyby sympatycy M$ zorganizowali coś podobnego pt tytułem "Windows- u mnie działa" to mielibyśmy niezły powód aby się ponabijać, więc radzę autorom takich jak ten lub "wioo" pomysłów na nazwę, aby się ogarneli /umnie -?/
Duby smalone bredzisz
u tych 10 osób które przyjdą może faktycznie działa – ale dla 99% procent użytkowników komputerów nie.
Koniec kropka.
Za dwa lata – Linux wciąż korzystam
Za cztery – Linux czemu w ciągu kilku lat dostał w dupę od BSD i padł
Amen.
chyba dlugosc brody tego stwierdzenia sprawia bol…
wiadomo, ze to nie jest system dla kazdego, co za
odkrycie?
Papier toaletowy jest dla każedgo – ^H! Nie dla każdego!
skąd masz te dane? że 99% użytkownikom komputerów linux nie działa? Czepiam się, ale nie siejmy FUDu
No na 99 % nie działa, bo 89% używa Windowsa, a 10% Mac OS X.
Operating System Market Share
To samo pewnie pisałeś 2,3,4,5 lat temu. I będziesz pisał dalej… Wbrew faktom. Tak się składa, że FreeBSD jako system desktopowy jest niemal niezauważalne i tak naprawdę wypłynęło na fali Linuksa. Bo jakoś nie słyszę, żeby linuksowcy narzekali, że nie mogą odpalić programów z FreeBSD, za to ile razy słyszę o zaletach FreeBSD to wymienia się możliwość uruchamiania linuksowych programów we wbudowanej w FreeBSD emulacji. To o czymś świadczy.
@Sparrow1: 2, 3, 4 i 5 lat temu sytuacja wygladala dokladnie tak samo – Linux mial pomijalnie maly udzial na desktopach i problemy z obsluga popularnego sprzetu.
Z jakim to popularnym sprzętem ma dzisiaj problemy Linux? Poważnie pytam. Mam go u siebie w domu na 3 kompach, przekonałem kilku znajomych i u wszystkich działa bezproblemowo.
Za to problemy XP z instalacją na dyskach SATA doczekały się już stałych tematów na forach. Gdyby takie sztuczki jak z XP trzeba było robić w Linuxie, to zaraz podniósłby się krzyk jaki to do d*** system. A w windowsie? No cóż, nowy sprzęt, ma prawo nie działać… :/
@AdeBe: Z dowolna karta graficzna inna niz nVidia, na przyklad.
intelhda – no sorry ale to żenada
Problemy z instalacją XP na sata? Słyszał o XP SP2sp3?
Nowoczesne systemy plików
Wykład o NTFS?
tak, dla uzytkownikow win 98
Wykład mniemam ten sam co na rootfest#0
Trochę będzie poszerzony.
Dlaczego znow Win7 i NTFS ??
Mam nadzieję, że rozumiesz różnicę pomiędzy "nowoczesnym systemem plików", a systemem plików reklamowanym jako taki przez producenta?
A dlaczego niby NTFS nie jest nowoczesnym systemem plików (fakt że ostatnia wersja była wydana w 2001 roku, ale…)? Co musi zawierać FS by można było go nazwać nowoczesnym?
@PACH: Musi byc Linuksowy. ;->
No tak jak myślałem żadnych konkretów. Szkoda bo miałem ochotę dowiedzieć się czegoś ciekawego.
BTW xd bo twórcy ext4 czy btrfs nie reklamują swoich systemów jako nowoczesne.
@PACH: ext4 to ta sama 'nowoczesna technologia', co w XFS dekade temu. BTRFS troche lepiej, tylko ze nadal nie dziala.
@trasz: Nikt nie mówi, że Ext4 jest ostatnim krzykiem mody, co wynika choćby z tego, że wciąż trzyma brzemię Ext*, ale jest to też, jakby nie patrzeć, jego zaleta. XFS zakłada sprawne dyski, a nie każdy desktopowy użytkownik może sobie pozwolić na RAID1 czy RAID5 o bardziej skomplikowanych konfiguracjach nie wspominając. Ext4 z obsługą bad blocków ma więc jednak pewną przewagę nad XFS.