Temat: odpowiednik dyskowego rozmiaru klastra ntfs windows w...

Andrzej Kosela:
Piotrze, wycieczki ad personam możesz naprawdę nam tu wszystkim zaoszczędzić.

Nie ustawiaj się w pozycji wieszcza. Pisz za siebie.

Wiem też, że bardzo trudno Ci teraz będzie wyjść wiarygodnie z tej pozycji do której się sam zapędziłeś. Rozumiem także, że Twoje wypowiedzi to takie lustro psychologiczne -- sam kreujesz się na "miszcza magika", a nie wiedziałeś, że ext2 jest szybszy od ext3 :)

Po prostu ręce opadają. Błagam oszczędź tej swojej logiki meandrycznej.

Wydaje mi się, iż *najpierw* było zrobić swoje "testy", a dopiero później wypowiadać się w wątku, bo jak na razie to nie wniosłeś za wiele ciekawego oprócz dość kontrowersyjnych tez dotyczących szkodliwości "googlania".

Mówił chłop do drzewa. Proszę, dość.

P.

Temat: odpowiednik dyskowego rozmiaru klastra ntfs windows w...

Andrzej Kosela:
Google is currently in the middle of upgrading from ext2 to a more up
to date file system. We ended up choosing ext4. This thread touches
upon many of the issues we wrestled with, so I thought it would be
interesting to share. We should be sending out more details soon.

The driving performance reason to upgrade is that while ext2 had been "good
enough" for a very long time the metadata arrangement on a stale file
system was leading to what we call "read inflation". This is where we
end up doing many seeks to read one block of data. In general latency
from poor block allocation was causing performance hiccups.

We spent a lot of time with unix standard benchmarks (dbench, compile
bench, et al) on xfs, ext4, jfs to try to see which one was going to
perform the best. In the end we mostly ended up using the benchmarks
to validate our assumptions and do functional testing. Larry is
completely right IMHO. These benchmarks were instrumental in helping
us understand how the file systems worked in controlled situations and
gain confidence from our customers.

For our workloads we saw ext4 and xfs as "close enough" in performance
in the areas we cared about. The fact that we had a much smoother
upgrade path with ext4 clinched the deal. The only upgrade option we
have is online. ext4 is already moving the bottleneck away from the
storage stack for some of our most intensive applications.

Jest co prawda późno i mogłem przekręcić ale czy czasem powyższe nie sprowadza się w telegraficznym skrócie do "używaliśmy ext2 ale z powodów wydajnościowych zdecydowaliśmy się na migrację do ext4" ?

Temat: odpowiednik dyskowego rozmiaru klastra ntfs windows w...

Łukasz M.:

Andrzej Kosela:
a nie wiedziałeś, że ext2 jest szybszy od ext3 :)

A czy nie jest raczej tak że to *system plików bez kroniki* jest w operacjach zapisu szybszy od *systemu plików z kroniką* a nie konkretnie ext2 od ext3/4? Co się stanie jak w ext{3,4} wyłączę kronikę za pomocą tune2fs -O ^has_journal /dev/x, czy aby nagle nie okaże się, że jednak to nowsze ext'y są szybsze bo mają trochę innych przyspieszaczy a jedyne co je spowalnia to troska o bezpieczeństwo danych?

Generalnie ext3 to ext2 + journal inode, także jeśli wyłączymy journal poprzez tune2fs(8) w ext3 to rzeczywiście uzyskamy zbliżone wyniki. Pierwotnie ext3 był systemem mogącym pracować niejako w dwóch trybach -- w tej chwili kod trochę się rozjechał, także warto by sprawdzić dokładne róznice między ext2 a ext3 - journal.

Warto sięgnąć także do źródeł i poczytać myśli twórcy ext3, Stephena Tweede:

http://e2fsprogs.sourceforge.net/journal-design.pdf

Musimy także pamiętać, że journaling nie jest także taki wspaniały i nie zabezpiecza nas tak naprawdę w 100% przed utratą danych. Nie od dziś istnieją znane i ciekawe alternatywy co do journalingu, jak Mckusick's FFS softupdates, czy różne implementacje COW (copy on write).Andrzej Kosela edytował(a) ten post dnia 07.12.10 o godzinie 00:52

Temat: odpowiednik dyskowego rozmiaru klastra ntfs windows w...

Andrzej Kosela:

Łukasz M.:

Andrzej Kosela:
a nie wiedziałeś, że ext2 jest szybszy od ext3 :)

A czy nie jest raczej tak że to *system plików bez kroniki* jest w operacjach zapisu szybszy od *systemu plików z kroniką* a nie konkretnie ext2 od ext3/4? Co się stanie jak w ext{3,4} wyłączę kronikę za pomocą tune2fs -O ^has_journal /dev/x, czy aby nagle nie okaże się, że jednak to nowsze ext'y są szybsze bo mają trochę innych przyspieszaczy a jedyne co je spowalnia to troska o bezpieczeństwo danych?

Generalnie ext3 to ext2 + journal inode, także jeśli wyłączymy journal poprzez tune2fs(8) w ext3 to rzeczywiście uzyskamy zbliżone wyniki. Pierwotnie ext3 był systemem mogącym pracować niejako w dwóch trybach -- w tej chwili kod trochę się rozjechał, także warto by sprawdzić dokładne róznice między ext2 a ext3 - journal.

Ale ext4 to już nie tylko kronika.

Temat: odpowiednik dyskowego rozmiaru klastra ntfs windows w...

Łukasz M.:

Andrzej Kosela:
Google is currently in the middle of upgrading from ext2 to a more up
to date file system. We ended up choosing ext4. This thread touches
upon many of the issues we wrestled with, so I thought it would be
interesting to share. We should be sending out more details soon.

The driving performance reason to upgrade is that while ext2 had been "good
enough" for a very long time the metadata arrangement on a stale file
system was leading to what we call "read inflation". This is where we
end up doing many seeks to read one block of data. In general latency
from poor block allocation was causing performance hiccups.

We spent a lot of time with unix standard benchmarks (dbench, compile
bench, et al) on xfs, ext4, jfs to try to see which one was going to
perform the best. In the end we mostly ended up using the benchmarks
to validate our assumptions and do functional testing. Larry is
completely right IMHO. These benchmarks were instrumental in helping
us understand how the file systems worked in controlled situations and
gain confidence from our customers.

For our workloads we saw ext4 and xfs as "close enough" in performance
in the areas we cared about. The fact that we had a much smoother
upgrade path with ext4 clinched the deal. The only upgrade option we
have is online. ext4 is already moving the bottleneck away from the
storage stack for some of our most intensive applications.

Jest co prawda późno i mogłem przekręcić ale czy czasem powyższe nie sprowadza się w telegraficznym skrócie do "używaliśmy ext2 ale z powodów wydajnościowych zdecydowaliśmy się na migrację do ext4" ?

Łukaszu, ext4 jest generalnie dużo szybszy w odczycie i niemal tak szybki (zależy jak skonfigurujesz parametry filesystemu) w zapisie jak ext2.

Temat: odpowiednik dyskowego rozmiaru klastra ntfs windows w...

Czy mam zatem rozumieć, że pisząc

Jak przejdziecie na ZFS to zapomnicie tak o NTFS jak i ext3/4.. A tak nawiasem mówiąc to co do wydajności w Linuksie nadal najszybszy jest ext2 :)

Miałeś na myśli, że ext2 jest szybszy w zapisie od ext3? A cała dyskusja toczy się wokół tego czy kronika spowalnia ext3 w stosunku do ext2?
Jeśli tak to zazdroszczę Wam zmartwień których ewidentnie nie macie skoro kłócicie się o takie pierdoły ;)

Temat: odpowiednik dyskowego rozmiaru klastra ntfs windows w...

Andrzej Kosela:

[...]

No dobrze, to przeanalizujmy wszystko od początku, bo ktoś tutaj chyba naprawdę zaniedbał lekcje logiki na studiach...

Ależ ja się nie wypowiadałem na temat meritum. :) Mi tylko kwestia
logiki rzuciła się w oczy. Chodzi o to, że tu nikt nie neguje wiedzy
jaką można zdobyć szukając w sieci. No, przynajmniej z tego co
przeczytałem. Istotne jest to, że warto samemu sprawdzić. Ja dla
przykładu różne rzeczy wypisuję na GL - czasem głównie w celu
podgrzania atmosfery i wyciągnięcia czegoś ciekawego z rozmówcy.
Dlatego właśnie wiedza zdobyta w Internecie powinna podlegać
zweryfikowaniu.

Journaling jest po to, żeby zapewnić spójność danych, a nie
zapobiegać ich utracie. Niby nic, ale jest różnica.

Dziękuję za podanie alternatyw dla journalingu - przetestuję - może
się kiedyś przydać.

Temat: odpowiednik dyskowego rozmiaru klastra ntfs windows w...

Łukasz M.:

(Ściana tekstu)

Jest co prawda późno i mogłem przekręcić ale czy czasem powyższe nie sprowadza się w telegraficznym skrócie do "używaliśmy ext2 ale z powodów wydajnościowych zdecydowaliśmy się na migrację do ext4" ?

Dokładniej "chceliśmy coś lepszego od ext2 bo w niektórych przypadkach nie działał zbyt dobrze więc sprawdziliśmy XFSa i ext4, wyszły podobnie, więc wzięliśmy ext4 bo upgrade jest łatwiejszy.

A przed utratą danych raczej żaden magiczny system plików nas nie zabezpieczy, chodzi bardziej o to żeby to co zostało na dysku było czymś używalnym, czyli starą wersją pliku, a nie jakieś losowe bajty, jak to się działo w ext2/3/4