No to si musime rozkliknou odkaz ... stale nic ? - pak si nedlej starostio, chyba neni na tvoji strane, ne kazdemu je z hury dano a ne kazdy je tak genialni, ze to pochopi uz z grafu ;-) krom dentalnich popisu - dnes ani neznalost anglicty neni problem, browser umi prekladat ....
A na obrazku je i takova sipka, kde znamena, zda nizsi nebo vyssi hodnota je lepsi, kdytz ukazuje doleva, tak niozsi, kdyz doprava tak vyssi ... a pak rika zda se Jedna o I/O, Latenci a nebo propustnost
Latence byva v ms nebo us, I/O je jasna to jsou operace za sekundu a propustnost dnes byva v MB/s
Ja si mywslim ze omladina to ma z tohop ockovcani hlinikem, nas ockovali trtuti a takove dusledky to nemelo ... a hlavne me se bali naocokovat - tak jsme vetsinu detskych nemoci prodelal a neockovali me ;-) .. a diky tomu mi lekar nadava, ze me 20 let nevidel ... proc byt me mel videt, kdyz mi nic neni ;-) ... teda je, ale s tim nic nenadela, mel bych shodit par kg ...
Hele, od zprávičky nečekám, že tam bude detailní analýza výsledků a zvolené metodiky, což by ve výsledku vyšlo třeba na celý seriál článků zde, ale nějaký souhrn v čem vlastně ty filesystémy soutěžily, to by se sakra hodilo. Takhle to číslo může znamenat cokoliv. Například kolik guadalupských pěstitelů banánů se třemi dětmi se má po testu lépe.
Takhle to číslo může znamenat cokoliv.
Muze, vsak to je uplne v poradku.
Jestli te ten test zajima, tak si to holt budes muset rozkliknout (dva kliky mysi uf!) a podivat se na nastaveni testu a dilci vysledky.
Jestli je ti to jedno, tak tam ti pestitele klidne muzou byt.
Btw. jak bys ten clanek z phoronixu shrnul ty, aby to odpovidalo tve predstave?
Nijak, nečetl jsem ho a ani číst nechci. Jen poukazuji na nedostatek této zprávičky.
Když linkuji do zprávičky graf, tak považuji za lepší dát nějaké informace k jeho interpretování. Takhle je to vše na úrovni „Phoronix testoval souborové systémy. Některé jsou lepší než druhé. Vše ukazuje barevný graf." Druhá věta je vlastně zcela očekávatelná, tak je to zprávička na úrovni „Phoronix testoval souborové systémy. A má barevný graf.“
Například informace o použitém disku je zcela irelevantní. Při použití jiného disku/SSD by výsledky byly pravděpodobně ve stejném poměru, jen absolutní číselná hodnota by byla jiná. Místo toho by se hodila věta, že měřili tyto, tyto a tyto parametry FS.
Na disku samozřejmě záleží. Na pomalém HW budou výsledky všech FS prakticky stejné - HW limited.
Nevím co si představujete pod "měřit tento parametr FS", ale trochu jsem ty testy rozepsal. Jako vždy si Michael z Phoronixu prostě vybere nějaký mix testů ze svého PTS a na tom to pustí. Ten výběr je víceméně náhodný.
Koho zajímá výkon FS pro konkrétní zátěž, tak to si holt musí změřit sám.
S tím diskem máš samozřejmě pravdu, proto je tam „/SSD“. Ale jádro mého sdělení bylo jinde. Účelem testu nebylo testovat SSD, ale filesystém, tak předpokládám, že testovací prostředí bylo použito pokaždé stejné. Tedy i SSD. Pak je zcela jedno jaké. Osobně mne tedy tato informace vůbec nezajímá, spíš mi chybí to shrnutí jak ty FS testovali. To je to podstatné. Až budou testovat 10 různých SSD s XFS, tak bude zajímavé, která SSD použili.
Mimochodem, na pomalém HDD by ty výsledky mohly být zcela jiné, ale ne prakticky stejné, kvůli jinému počtu IO operací nutných k přečtení či zápisu daných dat (různá struktura metadat a přístup k nim).
Bylo to známé omezení. XFS byl navržen pro servery, takže se počítalo s tím, že tam je UPS a dochází ke korektnímu odpojení souborového systému. Při nekorektním odpojení mohlo dojít k poškození dat v souborech, do kterých se právě zapisovalo. No a aby XFS signalizoval, že se se souborovým systémem stalo fakt něco špatného a aby po restartu nezačala aplikace vesele používat poškozený soubor (a na poškození by se přišlo později, až by třeba už byly pryč zálohy), při startu XFS takový soubor vynuloval.
Což se samozřejmě nelíbilo těm, kdo neměli ani zálohy ani UPS a byli by rádi aspoň za část toho poškozeného souboru.
Ahoj. Asi bych neřekl, že tam byl vyloženě bug.
Spíš to od začátku bylo u SGI navrženo na servery, co mají určité pracovní prostředí, odpovídající hardware a výkon je priorita. Tzn. podobně jako třeba u serverového JFS to nemá žádný režim se zápisem dat před metadaty (je to podobné jako když u ext4 nastavíš journal=writeback).
Zatímco to zmíněné ext4 má výchozí režim journal=ordered, což zdědilo po ext3, kdy se snaží nejdřív zapsat data, pak metadata přes žurnál. To má samozřejmě určitý vliv na výkon, ale vzhledem k majoritnímu nasazení ext3/4 na běžných počítačích to dávalo/dává smysl jako rozumný kompromis.
Postupem času po portaci XFS přibyla také podpora pro linuxové bariéry zápisu (možná 15-20 let zpátky s jádry 2.6). Což je sice odlišný mechanismus od toho orderingu a zajišťuje to persistentní zápis do disku (třeba přes FUA, nebo explicitním flushování hw cache), ale také to cílí na snížení pravděpodobnosti kritických problémů po neplánovaných výpadcích. Co vím, tak to XFS používá na zápisy do žurnálu a samozřejmě také pokud aplikace explicitně zavolá flush().
Nejdřív se bariéry daly explicitně vypnout (nobarrier), pak tam sice zůstal ten mount option, ale nic to nedělalo, a nakonec to 4.19 odstranili úplně, takže bariéry jsou pořád aktivní.
Ne nikdy tomu tak nebylo ;-) byla tam moznost odstranit barieru a tim jej zrychlit a omezit konsistenci, ale pary jsme testoval a vzdy vse opravil, jen se nesmi pouzivat fsck.xfs ale nejnovejsi xfs_repair
A clovek se nesmi bat, nejhorsi pripad co jsme zazil byl fakt, ze byly poskozeny oba dva journaly , tak jsme je smazal, udelal check vsech 20TB dat a on je pak vytvoril znova ... data se neztratila zadna ...
jediny FS co jsme videl opakovane rozj*** tak ze s tim neslo nic udelat je ten, co nema opravnou utilitu, ma nejaky jako ze export imp[ort s checkem struykjtury, bud to nebezi, teda bezi klidne 20 let ale nic to nedela, nebo solaris tam to dobehne a rekne ze to neumin opravit ... a na moje slova dolo a uz jsme zdilel odkazy, kde za to, za co mi nadavali pak uznali jako oficlni chyby a ze mam pak FS smazat, vycstit bloky, znova vytvorit zpooly, zraidy a obnovit ze zalohy ;-) ---
ZFS je tak smejd a nikoho realne nezajima ;-) , NTFS je shit, zkopirovany HPFS z OS/2 ... dokonce i s bugem z 386, kdyz vnzikl OS/2 HPFS+ nebo tez HPFS.386 - co opravoval chybu poskozeni FS pri svazich nad 20GB nebo 60GB ... to v te dobe nikdo nemel ... no a win2000 u toho znicily NTFS ;-) a ja se valel smichy, ze zkopirovali i ten znamy bug ;-)
ExdFAT neni FS ;-) ten by prohral na plne care, FAT je takova divna struktura, vhodna na zapais medii, tedy velkych souboru s linearnim zapisem a lineranim ctenim, zadny random a jine lahudky ... NTFS linux umi a nuemi - neni vubec urcen na provozovani a to an i kwernelovy modul, ani fuse modul - je urecen na migraci dat a zachranu windows - ne na provoz
Cili zvioli ty nejlepsi FS co linux ma a ty nejpouyzivanejsi ;-) ... ne nadarmo si RH do svych RHEL vybral jako defualt FS XFS ... sice nechapu, proc zrusili BTRFS a odstranili jej tam i z kernelu ;-) chapu se delat v tom raid5 je blbost, jka tvrdim ze i mirror ;-) ... jka tvrdim, ze BTRFGS patri na dikjove pole, nebo SW raidf nad tim ;-) a ziskame tak dedupliokaci, kompresi a super nspshoty, snap clony a blokove replikace vcetne verzovani
Ona to byla hlavně nafouknutá bublina. XFS byl považován za systém pro lidi, kteří vědí, co dělají, před použitím si přečtou dokumentaci. A ti o té vlastnosti věděli a používali XFS jen na serverech zálohovaných UPS. Pokud si někdo nainstaloval XFS, protože někde zaslechl, že je cool, a používal to na počítači bez UPS, byl to jeho problém…
O kterých blocích se bavíme? Když jsem se to před lety snažil pochopit, narazil jsem na rozdílné velikosti bloků pro zápis, mazání a ještě pro něco (čtení?). Navíc ne vždy to jsou mocniny dvou, protože s TLC jsme na třech bitech na buňku. Tehdy jsem naznal, že asi stejně se to spoléhá na nějaké mechanismy controlleru, který dělá wear leveling apod., a že pokud s tím nechci strávit kdoví kolik času, tak defaultní nastavení asi nebude tak špatná volba.
A jinak si matně vzpomínám, že někde v nastavení svého SSD (Samsung 990 Pro) jsem viděl, že na nějaké úrovni používá 512B bloky a ideální by bylo přepnout na 4K bloky. Dostal bych tím nějaké procento výkonu navíc, ale vyžádalo by si to formát SSD, a nechtělo se mi do toho.
Přesně jak bylo zmíněno v předchozím postu. Podle mě tak trochu motáte velikost erase bloku na SSD (řádově megabajty), velikost stránky v SSD a pak velikost logického sektoru, který bývá typicky 512B nebo 4K (8k a 16k zřídkakdy). To je pak velkost, co používá bloková vrstva při čtení nebo zápisu do disku.
Když si spustíte 'lsblk -D' tak vám to vypíše tuhle hodnotu u všech disků v systému (stejné ioctl pak podle mě používá i bcachefs, když vytváří nový fs)
Některé disky tu velikost logického sektoru umí měnit, např. mezi 512, 4096, 8192 B. Ale zas jak bylo zmíněno, je to nutně destruktivní operace, protože se musí vytvořit nová FTL mapa v disku.
Ve většině případů nemá smysl tuhle hodnotu nastavit větší než velikost paměťové stránky v systému.
Na x86 je to 4096 B (getconf PAGE_SIZE). Poměrně dlouho celá VFS vrstva i filesystémy nepočítaly s tím, že by mohla být větší velikost bloku u filesystému než stránky.
Je to docela boj, protože bylo v jádře poměrně spousta míst, kde se to muselo upravit. Viz. hezké povídání o dlouhé snaze a postupných krocích tohle omezení obejít.
https://kernelnewbies.org/KernelProjects/large-block-size
V jádře 6.12 je první verze XFS, která podporuje větší velikost bloku (až do 64k) než velikost pamětové stránky.
Něco předtím probíhalo i u F2FS, kdy to umožňovalo použít 16k blok na platformách, kde to sedělo s velikostí stránky (třeba ARM), ale to jsem netestoval.
Takže ne, 1 MB rozhodně není velikost, co byste chtěl nebo mohl nastavit jako blok filesystému. Maximálně si můžete pohrát s nějakým zarovnáváním interních struktur na hranice erase bloku nebo stránky. Tzn. použití stripe/stride u ext4, sunit/swidth u XFS jako u RAIDu, ale i to je poměrně diskutabilní, je tam spousty faktorů a musí se to vždycky individuálně ozkoušet.
-D, --discard
Print information about the discarding capabilities (TRIM, UNMAP) for each device.
Jste si jistý že to ukazuje potom správně? Myslím tím zrovna Advanced format.
Viz tohle SSD.
výstup smartctl
Sector Sizes: 512 bytes logical, 4096 bytes physical
lsblk -D
sda 0 4K
Tak ano. Tak ten výstup z lsblk je dobře. jen jsem přemýšlel přes příspěvek.
13. 5. 2025, 10:26 editováno autorem komentáře
spousta názorů a zkušeností...já v minulosti o data přišel s ReiserFS. XFS jsem používal dlouhou řadu let a v podstatě nebýt přechodu na BSD, používal bych jej stále. Bohužel z FreeBSD byl vyřazen již před lety a tam teď vše sází na ZFS, ke kterému stále nemohu najít důvěru a všechna data mám zrcadlena ještě na jinde na stařičkém, ale spolehlivém UFS2.
Každý test je třeba brát s rezervou, ale pro zajímavost bych rád viděl, jak by dopadl HAMMER2, i když tam by to bylo ovlivněno rozdílným výkonem celého systému.