Vlákno názorů k článku
FreeBSD 8 vylepšuje nejen síťování

Pokud vim, tak FreeBSD pouziva zcela jiny licencni model nez linuxove jadro a vsechny ostatni GNU utility. Mozna je to pro dobro veci, mozna ne, ale tvrdit, ze nekdo neco zaspal, je prinejmensim hodne odvazne tvrzeni.

Mňo takže co konkrétně v článku není pravda? Že FreeBSD má NCQ AŽ letos? Linux ho má ve vanila jádře roky. Že FreeBSD má konečně USB2? Když linux UŽ ma USB3? Že NFSd UŽ umí zamykat? zero-copy v síťovém kódu AŽ teď? Konečně víc než 16 skupin na uživatele? Co grafika a X-ka (vim, vim: freebsd je hlavně pro servery, bla bla bla)? Že na odstranění big kernel locku se bude teprve pracovat?

Jak říkám, linux možná není ideální kus kódu, ale díky za něj. A myslím, že za něj děkuje i FreeBSD, když má linuxovou emulaci defaultně zapnutou a přejímá linuxové grafické drivery.

jakkoli je FreeBSD udajne „zaostale“ pri load 200 normalne komunikuje a pracuje. u linuxoveho jadra je load 80 konecna a bedna se otaci cudlikem :o)

Presne tak. Ono i na desktopu,kdyz neco na pozadi kompiluju se s Linuxem moc pracovat neda, ale FreeBSD v pohode. Mam kvuli tomu na notebooku(Debian) alias nice -n 20 gcc ...... :-)

Dulezite je pochopit ze FreeBSD ma jiny model vyvoje. Zatim c do linuxu se pridavaji nove fuknce kontinualne. FreeBSD drzi nekolik vetvi. To, ze je NCQ v REALEASE az ted neznamena, ze k current uz nebylo.

USB 2.0 ma FreeBSD uz davno. Mozna by si to chtelo clanek jen poradne precist. Do verze 8 byl implementovan alternativni stack. Ja napriklad s puvodnim nemel nikdy problem.

Me 16 skupin na uzivatele staci i na serveru a nikdy jsem na tento limit nenarazil. Kdyby to byl vyrazny problem, urcite by na to narazela spousta lidi a uz by se ten limit odstranil.

S X na freeBSD jsem ja osobne mel mene problemu nez napr. na Debianu. Tim nerikam, ze jsou X na FreeBSD lepsi nebo horsi.

To, ze tu Roman psal o nekterych problemech neznamena,ze na ne bezni uzivatele narazeji.

Linuxova emulace je urcite uzitecna vec. Urcite podobne jako napr. Wine. A kod nesdili jen FreeBSD z Linuxu, ale funguje to i obracene.

Pokud vasim stilem budu srovnavat FreeBSD/Solaris/Li­nux (a mozna i Windows) vzdycky muzu nadavat na kazdy z nich a rikat, ze je 100 let za opicema.

Pekne ste to napisali a bez zbytocnych emocii. Ten „akcny“ pan hore, je pekny priklad Linux-oveho kiddie ficiaceho na niektorej klikacej distribucii (take zvasty som naposledy pouzival ked som mal 19 a zacinal som s tuxom a vsetko ostatne bolo „shit“ :)

No proste klasika. Miesto hladania pozitiv, same plutie a chvastanie.
OMG, kedy to uz skonci :)

Pekny den prajem vsetkym *NIXakom

:)

Ano napsal to pěkně narozdíl od vašeho zbytečného příspěvku ;-)

OK, to beru. Díky za vysvětlení.

Me 16 skupin na uzivatele staci i na serveru a nikdy jsem na tento limit nenarazil. Kdyby to byl vyrazny problem, urcite by na to narazela spousta lidi a uz by se ten limit odstranil.
Tohle mě docela překvapilo. Ale typická je reakce, že by se to udělalo, kdyby to víc lidí potřebovalo. Vtip je v tom, že pokud používáme UGO oprávnění a ne ACL, tak se ACL právě často simulují pomocí skupin. Potřebuju k tomuhle souboru dát práva těmto 11 lidem, pak udělám skupinu a šup do ní těch 11 lidí. A už jsem měl i tu čest s lidma, kteří byli ve víc jak 16 skupinách. Bylo to na linuxu a vůbec jsem netušil, že kdybych tam měl FreeBSD, tak že by to byl problém.

Ostatně poslední dobou mě FreeBSD začíná docela překvapovat takovýmito drobnostmi. Vždycky jsem FreeBSD chválil za čistotu návrhu, za to, že vývojáři vždycky něco nejdřív promyslí a pak teprve pořádně udělají (nebo taky neudělají). A teď čtu o limitu na počet skupin, o tom, jak se snaží přeložit kernel bez IPv4 protokolu a vysekávají IP z vrstev, kde by nemělo, co dělat…

„A už jsem měl i tu čest s lidma, kteří byli ve víc jak 16 skupinách. Bylo to na linuxu a vůbec jsem netušil, že kdybych tam měl FreeBSD, tak že by to byl problém.“

Ne, nebyl. Nic proti Romanovi (autor clanku), je to dobry a vesmes pracovity programator a pro FreeBSD dela dlouhodobe hodne, ale propagacni clanky tohoto formatu by skutecne psat nemel, protoze zurnalista vazne neni. A v tomto pripade FreeBSD asi vic uskodi nez udela uzitku (on cely ten clanek je takovy… docela divny.. jak je videt i z mnoha zmatenych reakci v diskusi).

Vec se ma tak, ze po leta byl hardcodovanym defaultem limit na 16 skupin, a nebyl dynamicky nastavitelny, jedine manualni editaci a rekompilaci FreeBSD (tudiz vec, kterou uzivatele FreeBSD delaji i tak bezne s kazdym updatem a novym deploymentem).

Originalni limit na 16 skupin byl po dlouha leta povazovan za „strizlivy“ default (a uprimne, nikdo se o to moc extra nezajimal, proste tam jako default byl a hotovo) a pokud bylo do daneho prostredi potreba nasadit vetsi, kazdy si ho dle potreby zvysil (jako treba ja poslednich 10 let a ne, nezabralo to nikdy vic nez 20 sekund prace). Takze jediny, pro koho ma tato „novinka“ nejaky vetsi smysl, jsou primo kontextu-znali uzivatele FreeBSD, pro ktere ted odpada jeden extra krok v nasazovacim postupu. Celou tuto „novou feature“ vubec nebylo nutne v clanku zminovat, jen pak zbytecne, jak je videt, vznikaji problemy s pochopenim kontextu (neexistujiciho) problemu a vznikaji zbytecne historky typu „Posledni dobou me FreeBSD zacina docela prekvapovat, ted jsem dokonce cetl, ze…“

Takze znovu – ne, zadny problem ve FreeBSD nebyl, zmenil se zpusob, jakym se limit skupin nastavuje a ted misto 20 sekund zabere 0 az 10.

Tak to je zajímavé. Když se to podá takhle, tak to opravdu nevidím jako zvláštní problém. Ikdyž zrovna to, že se při každém deploymentu překládá systém znovu, já za výhodu nepovažuju. Ale to je jen můj soukromý názor a do této diskuse to nepatří.

Ale za tím, že mě FreeBSD poslední dobou začíná překvapovat, za tím si stojím pořád a nejsou to žádné zbytečné historky. Vždycky jsem na FreeBSD chválil tu čistotu návrhu, ač jinak mi FreeBSD opravdu k srdci nepřirostlo. Ale líbilo se mi právě to, jak vývojáři všechno pěkně navrhnou a rozmyslí. Typicky GEOM, krásná myšlenka, zajímavé vlastnosti. Přišlo to „pár“ let po tom, co Linux má md raid a nahrazovalo to ten starý nespolehlivý vellum nebo jak se to jmenovalo. Návrh skvělý, ale funkčně pouze RAID0 a RAID1. A poměrně často už slýchám názory typu „RAID5 je při dnešních cenách disků mrtvý, to nemá ani cenu implementovat“ (tiše ignorujíc RAID6). Takže jak říkám, pěkné promyšlené věci, dobře navržené s ohledem do budoucna, ale často mi chybí nějaká funkcionalita. A pak jsem si přečetl http://ivoras.sharanet.org/…reebsd8.html a objevil jsem tam věci typu:

Historically, BSD is the progenitor of all TCP/IP implementations and the IPv4 code in FreeBSD was sprawled across the network layers of the kernel, from device drivers to the higher socket layers. A recent initiative aims at fixing the layering violations in preparation to, at first, build a kernel without INET (i.e. IPv4) support, then build an IPv6-only kernel. 

Panics on „hot“ removal of devices with file systems mounted from them 

bsdlabel is (finally!) extended to support more than 8 partitions. The new limit of 26 partitions comes from the number of lower-case letters.

A když si k tomu přidám už zmíněný problematický běh z USB HDD, trampoty s iSCSI co jsem měl, a pár dalších drobností, tak si za svým původním tvrzením docela stojím.

BSD particie nie su PC BIOS particie.

Nehlede na to, ze clovek musi mit docela bujnou fantazii, aby ho napadl scenar, ve kterem pouzije vic nez 8 partitions…

Jedna fantastická myšlenka, máme iSCSI server, a používáme systém, co exportovaná partition, to lokální partition. Na 750GB disk se partition v průměru po 10–20GB naseká docela hodně. V současné chvíli máme 73 „oddílů“ na dvou discích (používáme vlastní systém postavený na device mapperu).

>> Jedna fantastická myšlenka, máme iSCSI server, a používáme systém, co exportovaná partition, to lokální partition. […] V současné chvíli máme 73 „oddílů“ na dvou discích

Ok. To je právě ta „docela bujná fantazie“, o které jsem psal :)

Jak dopadlo srovnání tohodle řešení s FreeBSD/ZFS a Solaris/ZFS?

To není nic bujného, prostě mám xGB a ty potřebuju pro klienty sekat jak housky na krámě.
Srovnání s FreeBSD dopadlo špatně, iSCSI target ve FreeBSD je… No dá se říct, že má pár výhod pro minimalisitcké nasazení, třeba z LiveCD. Pro jakékoliv produkční nasazení je nepoužitelný. Solaris neovládám moc dobře a moc mi nesedí. A proč ne ZFS, to je právě to, proč je tam tolik „partition“. My nechceme používat filesystém, když to není nutné (je to pomalejší, režie na správu FS, fragmentace atd…). A v tomto případě to opravdu potřeba není.

>> To není nic bujného

Když myslíte… Mít iSCSI partition pro každého klienta… :)

Co je na tom špatného? :-)
Ale teď pozor, máme to celé ještě trochu bujnější :-) každá taková partition je před iSCSI exportováním přidaná do md mirroru a totéž na klientu. Takže když si to člověk představí, tak je to HDD->„partition“->mdraid->iscsi->mdraid->klient. Někomu to může připadat vcelku přebujelé, ale jak md tak devicemapper mají naprosto zanedbatelný overhead a ty možnosti, co to přináší jsou k nezaplacení… Narozdíl od FS, kde čerstvě naformátovaná ext3 a na ní dd 10GB soubor má asi 10% overhead…

Však to také nikde netvrdím…

Chapem, ze sa musite pochvalit.

Zdrojaky na ten customized device mapper asi nezverejnite, ze? Neni to nahodou pod GNU GPL v2?

To je základní myšlenka, pochválit se, když to nikdo za mě neudělá :-) Ale přiznám se, že tady mi šlo hlavně o to ukázat, že existuje smysluplné a ne moc fantastické použití pro víc „partition“.

Co se týče zdrojáků, tak o tom uvažujeme, uvidí se, jak se to vyvine. Ale co se týče licence, GPL se na to nevztahuje. Device mapper je samozřejmě součástí jádra ale my ho nijak nemodifikujeme, pouze ho používáme. Device mapper funguje tak, že se mu řekne něco ve stylu:
/dev/mapper/xy:
linear /dev/sda1 0 500
linear /dev/sdb1 0 500
a on podle toho vyrobí zařízeni /dev/mapper/xy, které bude 1000 bloků velké a prvních 500 bude prvních 500 bloků z sda1 a za tím bude prvních 500 bloků z /dev/sdb1. A ten náš systém funguje tak, že si z disku načte první 1MB a v něm má nějaké struktury, podle kterých takovouhle mapper tabulku vyrobí.

Ten clanok je trochu zle napisany.

USB – jedna sa o prepisanie USB stacku, nie uvedenie podpory pre USB2.0.

zero-copy – opat zero-copy je vyuzivane vo FreeBSD uz dlho. Tentoraz ale prepisali BPF aby vyzival zero-copy. Toto je tam napisane dost jasne.

giant lock – projekt odstranovania giant lock trva uz niekolko rokov. Vacsina casti systemu ho uz nema. Stale sa najdu niektore casti, odkial ho treba odstranit (list). Ak sa nemylim, podobny stav je v Linuxe.

Takze nie je to take zle, ako ste pochopili.

Co se týče toho giant locku. Na FreeBSD 8 na mě při startu vyskakuje pořád ješte docela dostkrát něconěco-giantlock version. Na FreeBSD 7 (o osmiččce nevím) to bylo i u USB mass storage, takže sýstém s / na USB HDD byl poměrně GIANTed :-)
Co se týče linuxu, mám pocit, že tam už je kompletně odstraněn nebo při nejmenším z naprosté většiny subsystémů.

Pokud se nepletu tak v Linuxu je BKL neboli giant kromě některých předhistorických driverů ještě v reiserfs a NFS subsystému. Je ale fakt, že reiserfs se už normálně nepoužívá, a pokud jde o NFS, tomu je lépe se na Linuxu vyhýbat obloukem tak jako tak.

A linuxovy NFSd zamykat umi? Pokud myslite ten binarni bordel ve /var/lib, tak to neni zamykani – urcite to neni to co si pod tim predstavuju ja. Jedina rozumna implementace NFSd demona je prave do FreeBSD a v NetAppu(coz je vlastne taky FreeBSD).

Jenomže vývojáři FreeBSD nehrajou hru „kdo ho má delšího“. Oni s rozvahou vyvíjejí kvalitnější a spolehlivější kód. Jejich cílem prostě není mít první USB 3.0 apod. …ostatně proč taky?! Oni to nevyvýjejí kvůli tobě a tvým „děsně důležitým“ požadavkům.