Názory k článku
FreeBSD řady 5

Mohl by někdo do diskuse přihodit zkušenosti s pětkovou řadou, SMP stroji a VINUM disky? Subjektivní pocity, zlepšení, zhoršení atd. vítány :)

ve 5.x je gvinum coz je implementace vinumu pod geomem coz by snad konecne mohlo byt ok. ale hlavne tam pjd dopracoval podporu pro vsechny mozne raidy atd. coz je brutalne super a pro takove mensi nasazeni uplne nejlepsi (sam pouzivam v praci ten gmirror)

Celkem zajimavy souhrn. Ale par veci jsem nepochopil:

- z jakeho duvodu "freebsd-gcc != gcc"? Copak podpora FreeBSD neni v mainline GCC? (nevim, zdrojaky ted nemam po ruce). V cem se tedy freebsd-gcc lisi?

- proc autor nedoporucuje pouzivat gcc -O2? Pokud vim, tak optimalizace maji dost malo spolecneho s operacnim systemem a naopak dost hodne spolecneho s cilovym procesorem. Takze pokud si FreeBSD lidi upravili GCC tak, aby jim z neho padajici assembler lip vyhovoval (ale furt by me zajimalo proc :-), dost pravdepodobne se to netyka optimalizaci a tudiz nevidim duvod proc je nepouzivat.

- doufam ze se FreeBSD poucilo z Linuxu a DevFS trefili na poprve "spravne" aby si nezadelali na stejne problemy ktere resil Linux se svym devfs ve 2.4...

- proc autor misto "tedy" pouziva "ie."? Johanka ma asi dovolenou... :-)

Ale jinak pekny clanek.

Myslenka devfs se me docela libi ... slysel jsem, ze to chteji z jadra linuxu vyhodit. Nevite nahodou proc implementace na linuxu je "spatna"?
Diky

Hlavny dovod je asi to ze je to implementacia v jadre, v k2.6 pouzivaju spojenie hotplug+udev - takze sa pouzivaju standartne event (generovane vzdy) v spojeni s userspace toolom.
Podla mna je to cistejsie riesenie, oproti inkernel implementacii

ad gcc: gcc co je v base fbsd ma par veci upravenych + par veci pridanych atd. proto napr. neni doporuceno (a tusim to ani nefunguje) kompilovat world/kernel pomoci gcc z portu
ad -O2: gcc je zname tim ze produkuje spatny kod. napr. dost dlouho strasil problem kdy nejela knihovna libalias pri -O2 (pomahal jsem to opravovat) a byla to fakt kravina proc to nejelo (gcc spatne pochopilo nektere vazby)
ad devfs: mne funguje dobre.. je ale fakt ze nepouzivam zadne hotswap veci atd.
ad ie: no, psal jsem to tam protoze se mi to libi. navic. ie = id est coz je latinsky, ma snad nekdo neco proti latine?

Ja jsem nekde vykuchal a pouzil funkci strtod z FreeBSD libc, a nefungovala mi s optimalizacema, a pak jsem zjistil, ze to neni buga gcc, ale te funkce. Musi se to prelozit s -fno-strict-aliasing

no... ona je otazka ci je to chyba kdyz je potreba psat "urcitym zpusobem". ie. ze validni kod (ktery lze skoro vzdy napsat nekolika zpusoby) je validni jen "nekdy".... ja to nazyvam chybou prekladace

Nemas pravdu. "Strict aliasing" pravidla jsou v C imho minimalne od C90. Akorat drive jich kompilatory nevyzivali k uplateni optimalizaci, takze jejich porusovani nebylo poznat. Tohle je jasna chyba kodu a ne kompilatoru.

Chyba prekladace to neni. Najdete si v man gcc popis volby -fstrict-aliasing. ISO C99 predepisuje prisna pravidla pro aliasing. Pokud ceckovy program tato pravidla nedodrzuje, je to chyba v nem, ne v gcc. Protoze tato pravidla mohou byt nepohodlna, existuje popularni volba -fno-strict-aliasing (se kterou se preklada i Linux, pokud vim).

Nové FreeBSD vyjde na mé narozeniny, děkuju :-)
/sorry za OT/

a tenhle clanek vysel na moje ;)

a na moje umrel Elmer Bernstein... :/

Ja se zase na svoje narodil :-)

No a na moje se narodil Gross :(

Tak tomu rikam pech ;(

..a na muj svatek! :o)) Juu!

Prave jsem nainstalovat Debiana abych otestoval tuhle posledni major distro co jsem jeste nemel.

Dost me v tomhle clanku nalakalo to shapovani. Po precteni jsem sice dostahl jakehosi uspech s tc, ale stale si myslim, ze to neni to prave orechove.

Skoda, ze nevyslo drive... Mozna si ale vezmu nejakou starsi masinku a pohraju si. Skoda, ze vyjde az o semestru :)), avsak beta... no mozna :P

Tak pokud ti jde jenom o to shapovani (pf + ALTQ), tak si muzes hned testout OpenBSD, odkud to vylezlo.
Pokud se ti tedy nechce na tu betu, ktera bude IMHO dost stable :o]

Opravdu ALTQ vylezlo z OpenBSD? Myslel jsem že je to sada patchů pro všechny BSD.

Jeste jsem si vzpomel, ze M$ chce implementovat podobnou vec i v longohrnech...objektovy pristup na disk :)))

Jak je to s UFS2? Co nového přináší, jak se liší od starého UFS/FFS, jaké má výhody? Na webu freebsd.org jsem o tom nějak nic nenašel. Slyšel jsem že umožňuje větší filesystémy, ale nic konkrétnějšího.

jednak umi vetsi disky, jednak ma podporu pro acl a obecne rozsirene atributy... a vubec - vyssi verze = automaticky lepsi ne ;)

No, právě jsem čekal něco trochu konkrétnějšího než "a vůbec". Třeba ty větší disky. Jak velké? UFS2 má pořád omezení že bitmapa použitých bloků pro cylindrovou grupu musí být v jediném bloku. To docela omezuje velikost cylindrové grupy. Jak velký filesystém si pak můžete dovolit, aniž by se první grupa zaplnila seznamem všech ostatních grup? Rád bych viděl nějakou dokumentaci jak struktura UFS2 vypadá. O FFS a Ext2 je toho dost, o UFS2 jsem nic nenašel. Taky by mě zajímalo, jak je řešená zpětná kompatibilita. Když má staré FFS superblok 8kB za začátkem zařízení a UFS2 64kB, může se stát že tam budou superbloky oba, jak se pozná o který formát jde?

Celkově mě FFS přijde jako dost primitivní filesystém a když už se vývojáři FreeBSD rozhodli zavést něco nekompatibilního, tak toho měli IMHO využít k radikálnějším změnám než jen umožnění větších adres na disku a podpory pro ACL.

UFS2 taky přináší možnost udělat snapshot filesystému za běhu bez nutnosti odmountování (tzn. kopii filesystému, která je konzistentní a dále se nemění).

Další možností je fsck na pozadí na namountovaném filesystému, na který je možné během kontroly i zapisovat.

Podle dostupné dokumentace (http://www.mckusick.com/softdep/index.html) se mi zdá, že ani jedna s těchto vlastností není vázána na UFS2 a nevyžaduje změnu formátu filesystému (neb snapshoty jsou uloženy v obyčejných souborech).

Mimochodem, taky vám připadá, že fsck na pozadí je pěkná prasárna?

taky mam ten pocit ze to neni vazane na ufs2
a co se tyce bgfsck tak je to imho genialni vec...proc by to mela byt prasarna?

No, mam takovy divny pocit z utilit ktere se hrabou v namountovanem filesystemu (jiny priklad muzou byt online defragmentatory). Uznavam, ze pro nekoho co se na to diva ciste uzivatelsky a nezna zurnalovani to muze vypadat jako genialni vec :-)

praveze vtip je v tom ze se to NEHRABE na namountovanem fs ale na snapshotu,coz je neco uplne jineho...

Coz asi neni uplne pravda, protoze clovek obvykle chce opravit ten filesystem a ne snapshot.

asi takhle... jedine na co to v tom mountlem fs saha je ODoznaceni inodu ze jsou pouzivany (jestlize je toto nespravne). coz je naprosto bezpecna operace...

Asi nejenom inodu, ale i dalsich potencialne poztracenych polozek, jako jsou bloky.

Takze v tom mountlem fs se provadeji nejake operace na zaklade toho jak vypada ten snapshot, procez je nutne predpokladat nejakou korelaci mezi nimi. Ale to je problem, protoze mezi tim je ten fs mountovany read-write. Autori zjevne veri, ze tuto korelaci znaji, protoze maji pod kontrolou implementaci FFS v jadre. (A veri, ze se vubec da nejaka korelace najit, coz nejakym zpusobem omezuje tu implementaci fs, aby k poruseni te korelace nedoslo.)

Nu, a to mi prave prijde jako prasarna. Tradicni fsck pokud vim nepotrebuje znat nic jineho nez format dat na disku a implementace mu muze byt ukradena.

Navic mi vubec neni jasne jak se da nejaka smysluplna korelace (mezi snapshotem a aktualnim stavem rw-mountleho filesystemu) bezpecne zajistit.

Uvazujme nasledujici pripad. Byl smazan soubor a adresar ve kterem byl obsazen. tedy jadro smazalo polozku v nadrazenem adresari a chtelo oznacit inodu adresare i souboru jako smazanou, kdyz tu system spadl. Po restartu se vytvori snapshot a na nem se pusti fsck. Projde adresare a zjisti ze na tyto dve inody nevede zadny odkaz, tedy jsou ztracene a mely by se smazat.

Mezitim nekdo otevre ten smazany adresar, najde ten smazany soubor (ktery prozatim vypada jako nesmazany) a smaze ho. Pak vytvori jiny soubor v nejakem nesmazanem adresari. V tomto okamziku se muze stat, ze jadro pouzije pro tento novy soubor tu smazanou inodu. A mame problem, protoze ted fsck tu inodu prohlasi za ztracenou a vesele smaze, cimz zpusobi jednak ztratu dat (smazal se soubor, ktery se smazat nemel), a dale nekonzistenci filesystemu - kdesi je polozka v adreari ukazujici na neexistujici soubor.

Pokud se divite, jak je mozne otevrit ten smazany adresar a neco v nem delat, tak si prectete manualove stranky fhopen(2) a fchdir(2) nebo si zkuste predstavit ze na tom stroji bezi NFS server.

Tolik k te bezpecne operaci. Mozna to maji ve FreeBSD osetreno, ale tim ze je nutno sledovat takoveto okrajove pripady se vse komplikuje, prestava to byt genialni a sklouzava to do prasaren.

Navic si moc nedovedu predstavit jak by to vlastne melo byt osetreno.

jojo, bloky taky
to co popisujete prave resi softupdates. ty totiz "seradi" operace tak aby jejich vykonani bylo bezpecne, tj. at uz se bude ve vami popisovanem pripade dyt cokoliv nikdy nedojde k nebezpecnemu serazeni operaci (ie. 1:read 2:read 2:write 1:write, kde cislo je proces apod.) nevim co se stane ale je nutne si uvedomit ze ten fs je jeden a co se pak bude provadet nad nim maji v operaci softupdates ktere prave tomuto zabrani...
takhle to chapu ja

Bezpecne to je (pokud v tom nejsou bugy). fsck na pozadi na freebsd nedokaze odstranit vsecky chyby (napr. zpusobene vadnym hardware), dokaze odstranit jen ty, ktere vznikly po padu systemu --- t.j. ztracene bloky a inody.

Idea je takova, ze pokud je nejaka inoda ztracena na snapshotu, bude ztracena i na skutecnem filesystemu, takze se muze odstranit. Odstrani se tak, ze fsck zavola funkci kernelu pro odstraneni inody, nehrabe na zarizeni rovnou, aby se spravne vyresila synchronizace s buffery.

Na Linuxu je take mozno pustit fsck na namountovanem filesystemu, ale tam to skutecne bezpecne neni, a nema se to delat, pokud o ten filesystem nechcete prijit.

> Idea je takova, ze pokud je nejaka inoda ztracena na
> snapshotu, bude ztracena i na skutecnem filesystemu,
> takze se muze odstranit.

No to prave nemusi byt pravda, ke ztracenym inodam je totiz porad mozno pristupovat pres filehandly, pokud na tom stroji bezi NFS server ci se pouzije volani fhopen(2). A inody ke kterym je mozno (jakkoli) pristupovat neni radno odstranovat.

Inoda je fyzicky odstraněna, pokud její počítadlo hardlinků klesne na 0 a pokud její počítadlo otevření (drženo v paměti) klesne na 0. Takže pokud tu inodu někdo měl otevřenou před fsck, fsck ji neodstraní (pouze způsobí, že bude smazána, až bude zavřena). Pokud se ji někdo bude snažit otevřít po fsck, tak otevření vrátí chybu. Pokud se mezitím na daném místě vytvořil jiný soubor, měla by jeho otevření zabránit jiná verze (na Linux tomu zabrání, předpokládám, že FreeBSD to má taky).

A co kdyz ji nekdo otevre v prubehu fsck, tj. pote co byl vytvoren snapshot, ale predtim, nez fsck dobehl? Vyhoda bgfsck ma prave spocivat v tom, ze po tuto dobu bude filesystem plne pouzitelny i pro zapis, takze by mel fungovat i fhopen a NFS server.

Hej pripada a uz sa mi na tom raz zrubala masina a mal som nekonzistentny filesystem a musel som robit obnovu zo superblokov a prisiel som o dost dat :-(.

to je ale problem (levnych) ata disku, ktere lzou o tom jestli byla uz data zapsana na disk (aby ten disk vypadal papirove rychleji)... za tohle fbsd nemuze

ATA ma prikaz na flushnuti cache, FreeBSD ho umi pouzivat, o nem snad disky nelzou.

Linux tento prikaz neumi pouzivat (resp. pouzije ho pouze pri shutdownu), takze pokud pod Linuxem povolite cache pro zapis na disku, tak jsou data pri pouziti journaloveho filesystemu v nebezpeci (u nejournaloveho je to jedno, ale treba neni zaruceno, ze po fsync bude soubor ulozen).

praveze lzou... a o tom to je...

Jo, taky jsem slysel ze nektere lzou, protoze Win NT pri zapisu do zurnalu taky flushuje cache a kdyz ty disky lzou, tak dosahnou lepsich vysledku ve Win NT benchmarkach.

A které disky lžou? Která firma je dělá? Je o tom někde na internetu nějaká stránka nebo dokumentace? Taky mám ATA disky s povolenou cachí a zajímalo by mě, zda to data může poškodit.