Jaderné noviny – 23. 6. 2010 (diskuse)

[Mrkva]

Jediný knoflík pro nastavení napájení

Proč mi to jen přijde jako nesmysl? Uživatel který to nechce řešit se stejně do /sys koukat nemusí (nastaví to za něj distribuce) a ten, který chce rozhodně "jeden knoflík" využívat nebude.

[Roman]

a ten, který chce rozhodně "jeden knoflík" využívat nebude.

Proč ne?

[kralyk z abclinuxu]

nastaví to za něj distribuce

Tady je právě problém. Výsledek tohohle řešení je, že to buď v distribuci nefunguje pořádně, anebo to funguje ve sytlu "každý pes jiná ves".

[ext3fs]

Jsem pro knoflik. Osobne si radeji napisu maly skript na obsluhu napajeni (a nebo to budu prepinat rucne) nez pouzivat treba Spravce napajeni v KDE ktery si alokuje pres 100MB pameti (dost dobre netusim k cemu).

[frr]

Souhlasím, že 100 MB a závislost na knihovnách KDE je hrozně moc. Jinak mám ale pocit, že nastavení několika dílčích kernelových knoflíků podle nějakého jednorozměrného vstupního čísla je docela rozumná úloha pro triviální user-space prográmek nebo skript (pár desítek kB).

[Bedňa]

Btrfs dostal na prdel, kua tak z toho som ...

[frr]

No... dostal... zastánce ReiserFS překvapivě otestoval Btrfs maličkými soubory o konkrétní velikosti, a je z toho děsnej problém. Kdyby otestoval, jak je oddíl využit MPtrojkama, filmama nebo nějakým mirrorem FTP, došel by k úplně jinému číslu. A v praktickém nasazení bych čekal spíš tenhle typ dat. Mě by daleko víc zajímalo, kolik to generuje "režijních seeků" při sekvenčním čtení dlouhých souborů - tohle je v Linuxu problém.

[frEon]

kdyby disk osadil beznejma mptrojkama, filmama nebo nejakym mirrorem ftp, tak by tenhle bug nenasel. A zabugovanej filesystem nechce mit nikdo. Nebo ty jo?

[Aleš Kapica]

Edward Šiškin není žádný zastánce ReiserFS, ale Reiser4. Asi by tak "neřval" kdyby nebyl na rozdíl od Btrfs nebyl Reiser4 mimo jádro.

Pokud jde o mne, Reiser4 jsem nějaký čas k plné spokojenosti používal, ovšem přešel jsem právě na Btrfs. Důvody? Je v jádře. Je rychlejší a úspornější. Na mnoho prťavých souborů je možná Reiser4 lepší, ale při zaplnění disku nad 80% šel rapidně dolů jeho výkon, což u Btrfs problém není.

[Heron]

Jak psal frr.

+ ten FS je stále ve vývoji, takže vývojáři mohou poděkovat za nalezenou chybu (i když oznámenou takovým způsobem...) a mohou ji opravit. Do produkčního nasazení btrfs ještě pár let zbývá a u FS není kam spěchat (maximálně tak pro zálohu).

[al-Quaknaa]

Já mám btrfs na /, používám gentoo, takže tam je portage strom a další místa se spoustou malých souborů a už jsem na podobnou situaci narazil (že btrfs byl plný při ~65% využití). Ano, je stále ve vývoji, ale reiser4 se v tomhle ohledu choval vážně mnohem lépe... Samozřejmě se tyhle FS nedají porovnávat (jiné featury, návrh atd.), ale argument, že nejčastější užití bude jiné, než spousta malých souborů, mi přijde dost mimo.

[Heron]

byl plný při ~65% využití

To se ale stane velmi snadno. Většina FS (výjimkou je třeba Reiser) má nejmenší jednotku blok o velikosti 4kB (nebo i jinou -- zpravidla násobně větší). Tedy, pokud tam máš soubor o velikosti třeba 5kB, tak to zabere na disku dva bloky, tedy 8kB (jeden bok plný a ve druhém 1kB, 3kB jsou tedy "ztracené místo"). Pro 2kB dat je pak potřeba velikost 4kB. Tedy takový FS by byl plný při zaplnění 2kB soubory o celkové velikosti 50% velikosti FS (resp ještě méně než 50%, protože je potřeba další místo na adresářové struktury, a obecně metadata). To je prostě vlastnost, nikoliv chyba.

FS obecně umožňují velmi malé soubory uložit úsporně přímo v adresářové struktuře (to se ale netýká velikost větší jak blok). Reiser (volba tail) jde dál (jako imho jediný), umí využít místo z nezcela zaplněného bloku. Tím sice šetří místem, ale append na takové soubory je pomalejší.

ale argument, že nejčastější užití bude jiné, než spousta malých souborů, mi přijde dost mimo.

No jenže tak to prostě je. Pokud chceš ukládat data o velikosti cca 4kB (obecně velikost bloku na FS), tak to ukládat jako jednotlivé soubory na FS není vůbec nejlepší řešení (naopak je to jedno z nejhorších).

[frEon]

reiser defaultne spojuje konce souboru k sobe do jednoho bloku, takze timto problemem trpet nemusi. druha strana mince je, ze to mirne zpomaluje praci fs. Nastesti, kdyz clovek vi, ze mu vyhody prevazi nevyhody, tak to proste vypne

[Heron]

Nespletl sis komentář k reakci?

[frEon]

nj, mel bych se poradne vyspat... ber to jako OT

[al-Quaknaa]

To je prostě vlastnost, nikoliv chyba.

Aha - v tom případě mi tyhle věci nedocházejí proto, že už od svých linuxových začátků (~6 let zpátky, nepamatuju se) používám reiser3 a reiser4 a až nedávno jsem přešel na btrfs.

No jenže tak to prostě je. Pokud chceš ukládat data o velikosti cca 4kB (obecně velikost bloku na FS), tak to ukládat jako jednotlivé soubory na FS není vůbec nejlepší řešení (naopak je to jedno z nejhorších).

No, tohle je myslím věc názoru - sám Hans viděl databáze jako řešení problémů filesystémů a chtěl, aby se to tak dělat nemuselo (proto taky pluginy pro reiser4, které měly rozšiřovat schopnosti FS na něco, co se dnes v "sémantickém desktopu" řeší kombinací FS a databáze). Nemyslím si, že pokusy o zrychlení portage přehozením metadat do sqlite jsou důkazem toho, že se FS pro tento účel nehodí, ale že se většina současných FS pro tento účel nehodí. V praxi ten rozdíl asi moc velký není (protože kdo ví, kde reiser4 skončí), ale neviděl bych správu malých souborů jako něco, co pod FS nespadá.

Nakonec ale uznávám, že FS rozumíš o dost víc - já tu jen tlumočím své dojmy z toho, co jsem kdysi od Hanse četl a taky to, že se reisery na malých souborech chovaly o dost lépe (a u těch velkých jsem nějaký velký rozdíl neviděl. Pravda, nebyly to soubory o desítkách GB na oddílech velkých v TB).

[Heron]

No, tohle je myslím věc názoru...

Jasně, mezi DB a FS není žádná ostrá hranice (jak by mohla být, obojí slouží k ukládání dat).

Nemyslím si, že pokusy o zrychlení portage přehozením metadat do sqlite jsou důkazem toho, že se FS pro tento účel nehodí, ale že se většina současných FS pro tento účel nehodí.

Neznám portage ani jeho potřeby. Relační DB (sqlite je relační) obecně poskytuje pohled na data z mnoha uhlů (where přes x sloupců, join přes y tabulek) a k tomu vyžaduje spoustu režijních struktur (indexy, transakční logy, mvcc). Zatímco FS prostě vrátí data tak, jak se válí na disku, na základě jednoho identifikátoru (v relační DB bychom si pouze s primárním klíčem nevystačili). Takže na jednu stranu ano, bylo by fajn mít "DBFS" a použít jej tam, kde to má smysl, na druhou stranu ta nutná režie navíc by byla obecně neakceptovatelná. Pokud si pro portage vybrali sqlite (místo nějaké jiné a rychlejší db typu key-value), tak k tomu asi měli lepší důvod než jen jako skladiště malých souborů.

[Huiii]

Ale to Shishkin dobre vi, ve svem postu pise ze idelani vyuziti je max 0,5. On ale tvrdi, je vyuziti 0,17 je prilis male, ze ext4 a xfs jsou mnohem lepsi (ani jeden tail packing neumi).

A protoze se o Btrfs tvrdi, ze je to next-gen FS, tak by mel byt minimalne stejne dobry, jinak je to experimentalni vec nevhodna pro produkcni nasazeni. (A s tim plne souhlasim.)

[Heron]

Já také nepolemizuji s Shishkinem. Pouze jsem vysvětloval jak je možné mít plný disk při velikosti dat 63%.

17% je možná chyba (velikost bloku 12kB tam asi pro btrfs nastavenou neměl) a mělo by se upravit. Je to FS ve vývoji, chyb tam bude ještě dost.

[Bedňa]

Pokud chceš ukládat data o velikosti cca 4kB (obecně velikost bloku na FS), tak to ukládat jako jednotlivé soubory na FS není vůbec nejlepší řešení (naopak je to jedno z nejhorších).

Podľa toho názoru je vidieť že sa dožijeme aj šmejdu ext999 a všetko lepšie zadupeme. Kde si myslíš že sa DB ukladá tie prťavé dáta?

[Martin Mareš]

Ale vždyť ona je to pravda. Rozhraní souborového systému vůbec není stavěné na operace typu "přečti mi obsah všech těchto souborů v takovém pořadí, v jakém to bude nejrychlejší", což je jedna z nejtypičtějších databázových operací.

Hans Reiser měl zajímavou vizi o spojení sémantiky souborů a databází, ale bohužel k ní vymyslel pouze prostorově efektivní uložení malých fragmentů dat a ne už způsob, jak s nimi zacházet rychle.

[Bedňa]

Reiser s nimi vie robiť fakt rýchlo, bohužiaľ ďalší vývoj už nebude jednoduchý. Všetci veľký ľudia sú šialenci, uhladený programátor možno naklepe časť pekného kódu, ale nikdy nič prielomové. Samo že sa teším na stable btrfs inšpirovanú Reiserom, alebo na zmenu licencie k ZFS.

[kralyk z abclinuxu]

Spousta lidí vynalezla průlomové věci, a přitom byli duševně naprosto v pořádku...

[Bedňa]

Poznám kľučových hráčov, ale o normálnom neviem, napr.?

[kralyk z abclinuxu]

Teď rychle z rukávu mě napadá např. Wichterle. (předpokládám, že se nebavíme jen o IT sféře).

[Bedňa]

Samo že som nemyslel len IT, o tom človeku som si teraz prečítal prvý krát, normálne pôsobí len preto že možno nikto nerozpitval jeho súkromie. Ale pokiaľ poznáš človeka ktorého naozaj niečo nie že baví, ale úplne to žere, je to niečo ako heroin, kokain, automaty a bez dávky ...

[Bedňa]

A prd teraz som si spomenul že mi ho tatko spomínal, v súvislosti so Silónom.

[kralyk z abclinuxu]

normálne pôsobí len preto že možno nikto nerozpitval jeho súkromie

Když rozpitváš soukromí téměř kohokoli, tak nebude "normální". Já teda bych si netrouf říct, že včetně soukromí jsem naprosto "normální", ty jo?

Ale pokiaľ poznáš človeka ktorého naozaj niečo nie že baví, ale úplne to žere, je to niečo ako heroin, kokain, automaty a bez dávky ...

Ne, o tom jsem nemluvil, reagoval jsem na to, že duševně zdravý člověk nevynalezne něco průlomového... A čočky a silon jsou imho značně průlomové...

[Bedňa]

NO COMENT.

[Ash]

Prosím nechte toho, z paradoxních komentářů jako "bez komentáře" a podobně se mi točí hlava a je mi špatně :D

[kralyk z abclinuxu]

Ale on afaik nenapsal "bez komentáře", to se totiž řekne anglicky "no comment", čili co napsal zatím nevíme

[Bedňa]

Keď sa do niečoho zažerieš, tak ostatné veci sa ti zdajú nepodstatné, napríklad aj život tvojej manželky :)

[stativ]

Je přece evidentní, že to mělo být „no cement.“

[Ash]

NA BETON.

[Martin Mareš]

Reiser s nimi vie robiť fakt rýchlo

Ne, neumí. Zkuste si založit řekněme 100 milionů 10-bajtových souborů s náhodnými názvy a pak je všechny přečíst. Pak to porovnejte s přečtením stejných dat uložených pohromadě v jednom 1GB souboru. Rozdíl několik řádů.

[m;)]

a co UFS (FFS) rodina ? blok moze byt deleny na fragmenty. napr UFS2 ma blok 16 KB a fragment 2KB. na tieto veci sa myslelo uz davno. a ak ma niekto potrebu zaplnit disk 1KB subormi moze si tak nastavit velkost bloku (aj u 20 rocneho NTFS). 17% je proste "proklate" malo.

[Heron]

na tieto veci sa myslelo uz davno. a ak ma niekto potrebu zaplnit disk 1KB subormi moze si tak nastavit velkost bloku (aj u 20 rocneho NTFS).

Velikost bloku si můžeš nastavit u většiny FS. To ale na principu věci (tedy zápis souborů o velikosti přibližně velikosti bloku) nic nemění. Pro soubory do velikosti bloku bude vždy průměrná ztráta 50%. Malé bloky ale způsobují velkou režii pro FS, těch bloků je zkrátka moc*, bitmapa volného místa je pak příliš velká, nalezení volného rozsahu trvá déle apod.

17% je proste "proklate" malo.

To nijak nerozporuji.

*) Záměrně nepíšu kolik je moc. Pokud se bych měl říct, kolik je moc souborů, tak na běžném desktopovém disku jsem dosáhl použitelného (opět to záměrně nechám tako mlhavě definované -- prostě "to" bylo pomalé) limitu cca 700 000 souborů na ntfs a velmi podobného 600 000 limitu na ext3. Na 3.75TiB diskovém poli s xfs těch souborů mám cca 8 900 000 a už to začíná být takové všelijaké (zejména xfs_fsr má problém najít souvislý rozsah o dostatečné velikosti, nové 20GB soubory mají běžně 1200 fragmentů, což je cca 17MB/s, což už zpomaluje kontinuální čtení). Na mailling listu xfs se lze dočíst, že rozumné maximum je 10 mil souborů (nějaký šašek chtěl na jeden FS chtěl výhledově ukládat až 500 mil. souborů, na počátku "jen" 100 mil.). Vývojáři XFS ho poslali do ... DB (tím nemyslím nutně SQL relační).

[cronin]

Pro soubory do velikosti bloku bude vždy průměrná ztráta 50%.

Prave ze nie. Minimalne UFS/FFS deli bloky na tzv. fragmenty, ktore pouziva na kratke subory a "chvosty" dlhych suborov, cim vyznamne redukuje zmieneny problem plytvania miestom v poloprazdnych blokoch, a to zaroven pri zachovani dostatocne velkych blokov (typicky 8-16kB). Zil som v domneni, ze vsetky post-minix FS toto (alebo nejaku obdobu) robia - ak tomu tak nie je, je to pre mna dost velke prekvapenie.

Uznavam, ze testovaci pripad s uniformnou starostlivo vypocitanou velkostou suboru je znacne umely. Zaroven vsak treba uznat, ze efektivita vyuzitia miesta 17%, ku ktorej tym FS dotlacil, je pre general-purpose FS neospravedlnitelna; a IMHO ospravedlnitelnych nie je ani tych 65%. Keby sa jednalo o na nieco specializovany FS a zmieneny testovaci pripad by bol proste zamerny "misuse", tak to by bolo mozne autora poslat kade lahsie. V tomto pripade to ale vyzera ako chyba. Kazdopadne tvrdit, ze BTRFS je kvoli tomu zle dizajnovany per-se je - jemne povedane - prehnane. Ako dlho trva vyladenie komplexneho FS je dobre vidiet na ZFS. BTRFS je velmi mlady a bez ohladu na slubne vyhliadky ma pred sebou este velmi dlhu cestu.

[frr]

Jazykozpytná poznámka: nemám to podloženo nějakým autoritativním pramenem, ale pod pojmem "head banging" si osobně představuji figurku, která z čirého zoufalství buší hlavou do zdi, do desky stolu apod... Znáte takový ten vtipný obrázek formátu "A4", na kterém je terč a nápis "zde udeřit hlavou" ? A teď si s tím překladateli poraď :-b

[bubak]

head bangers jsou metalisti co na koncerte trepou hlavama.

[Bedňa]

Motorhead bangers.

[geebranz]

Have you solved this

fence companies green bay