abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 13:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. pražský sraz, který proběhne ve čtvrtek 26. října od 18:00 hodin v karlínském Pivovarském klubu. Najdete jej kousek od metra Florenc na adrese Křižíkova 17, Praha 8. Jedná se o poslední sraz před konferencí OpenAlt 2017, jež proběhne o víkendu 4. a 5. listopadu 2017 na FIT VUT v Brně. Běží registrace účastníků.

Ladislav Hagara | Komentářů: 0
dnes 06:00 | Zajímavý software

Byla vydána verze 0.56 open source platformy Home Assistant (GitHub) pro monitorování a řízení inteligentní domácnosti naprogramované v programovacím jazyce Python verze 3 a bežící také například na Raspberry Pi. Pro vyzkoušení je k dispozici demo [reddit].

Ladislav Hagara | Komentářů: 0
včera 16:55 | Nová verze

Byla vydána verze 1.0 klienta F-Droid určeného pro instalaci aplikací do Androidu ze softwarového repozitáře F-Droid (Wikipedie), alternativy k Google Play, nabízející pouze svobodný a otevřený software. Podrobnosti v přehledu změn [Hacker News].

Ladislav Hagara | Komentářů: 5
včera 00:55 | Nová verze

Po téměř 13 měsících vývoje od verze 0.11.0 byla vydána verze 0.12.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 9
21.10. 12:33 | Zajímavý software

Článek ne Medium představuje nejnovější stabilní verzi 2.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu [Hacker News].

Ladislav Hagara | Komentářů: 0
21.10. 06:00 | Komunita

V Praze na půdě Elektrotechnické fakulty ČVUT dnes probíhá RT-Summit 2017 – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt. Přednášky lze sledovat online na YouTube.

Ladislav Hagara | Komentářů: 0
20.10. 14:33 | Zajímavý projekt

Blender Animation Studio zveřejnilo první epizodu z připravovaného animovaného seriálu The Daily Dweebs o domácím mazlíčkovi jménem Dixey. Ke zhlédnutí také ve 3D s rozlišením 8K.

Ladislav Hagara | Komentářů: 0
20.10. 12:34 | Komunita

Aktualizovanou počítačovou hru Warhammer 40,000: Dawn of War III v ceně 39,99 eur běžící také na Linuxu lze o víkendu na Steamu hrát zdarma a případně ještě v pondělí koupit s 50% slevou. Do soboty 19:00 lze na Humble Bundle získat zdarma Steam klíč k počítačové hře Sid Meier's Civilization® III v ceně 4,99 eur běžící také ve Wine.

Ladislav Hagara | Komentářů: 0
20.10. 00:22 | Nasazení Linuxu

Společnost Samsung oznámila, že skrze dokovací stanici DeX a aplikaci Linux on Galaxy bude možno na Samsung Galaxy S8 a S8+ a Galaxy Note 8 provozovat Linux. Distribuce nebyly blíže upřesněny.

Phantom Alien | Komentářů: 19
19.10. 23:55 | Komunita

Společnost Purism na svém blogu oznámila, že její notebooky Librem jsou nově dodávány se zrušeným (neutralized and disabled) Intel Management Engine (ME). Aktualizací corebootu na již prodaných noteboocích lze Management Engine také zrušit. Více v podrobném článku.

Ladislav Hagara | Komentářů: 2
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (10%)
 (0%)
 (0%)
 (1%)
 (75%)
 (13%)
Celkem 226 hlasů
 Komentářů: 8, poslední včera 23:02
    Rozcestník

    Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů

    19. 8. 2014 | Luboš Doležel | Jaderné noviny | 3612×

    Aktuální verze jádra: 3.16-rc7. Citáty týdne: Dave Airlie, Andrew Morton, Greg Kroah-Hartman. Dvě cesty k lepšímu readdir(): xgetdents(); dirreadahead().

    Obsah

    Aktuální verze jádra: 3.16-rc7

    link

    Aktuální vývojová verze jádra je 3.16-rc7 vydaná 27. července. Linus je s tempem změn už spokojenější: Je jasné, že tam *máme* opravdové změny, ale nic z toho nevypadá děsivě. A rc7 je konečně znatelně menší než předchozí rc, takže se to zjevně uklidňuje. Navzdory mým dřívějším obavám možná půjde o poslední rc, uvidíme, jak se to vyvine příští týden.

    Stabilní aktualizace: verze 3.15.7, 3.14.14, 3.10.50 a 3.4.100 vyšly 28. července. Aktualizace 3.15.8, 3.14.15, 3.10.51 a 3.4.101 se právě revidují; jejich vydání můžeme čekat 1. srpna nebo později.

    Citáty týdne: Dave Airlie, Andrew Morton, Greg Kroah-Hartman

    link

    A pak zveřejníte zdrojový kód.

    A hele, zrovna jste vyšel z domu. Začlenění vašeho kódu je spoooustu kilometrů před vámi a teprve jste vyrazil na cestu, právě teď, ne když jste to začali psát, ne když jste začali dělat právní prověrku, ne když jste to interně počtvrté přepsali. Udělali jste to teprve až teď.

    -- Dave Airlie

    Ukazuje se, že jsem lehce úplatný. Kód vypadá čistě a jednoduše a nepřítomnost komentářů je osvobozující, akorát by lidi mátly.

    -- Andrew Morton

    Vždycky jsem doporučoval „Najděte si něco, co vám vadí, opravte to a pokračujte dál.“ A jestliže na svém stroji nemůžete najít problém s jádrem, pak se jen málo snažíte.

    -- Greg Kroah-Hartman

    Dvě cesty k lepšímu readdir()

    link

    Běžné používání systému souborů probíhá obvykle následovně: projít seznam souborů v adresáři a na každém zavolat stat() pro získání informací o každém z nich. Příkaz ls -l je typickou ukázkou této zátěže, ale najde se řada dalších příkladů. Tato operace na Linuxu vždy byla pomalejší, než by se vývojářům líbilo, a hledání řešení bylo ještě pomalejší. Abhi Das nedívno navrhl dvojici možných řešení; tentokrát se to možná opravdu vyřeší – tak trochu překvapivě.

    Problém s ls -l je dosti jednoduchý: pro každý zkoumaný soubor jsou potřeba dvě systémová volání. Volání getdents() (obvykle přes funkci readdir() v knihovně C) získá název souboru v adresáři; pak se zavolá stat() pro zjištění informací o souboru. Hlavně volání stat() může být náročné, každé volání nutí příslušný systém souborů uskutečnit I/O operaci pro získání požadovaných informací. V některých případech tyto údaje mohou být rozprostřené napříč vícero datovými strukturami na disku, což vyžaduje ještě více I/O, i když volající aplikace neupotřebí všechno to, co stat() vrací. Provádění veškeré této práce je neefektivní; bylo by pěkné moci omezit shromažďované informace na to, co aplikace opravdu potřebuje, a získávat tyto informace po dávkách.

    Tento problém není níčím novým; pravdou je, že byl starý už když se v roce 2009 probíral na Workshopu o linuxových úložištích a systémech souborů. Navrhované řešení, které mělo podobu systémového volání xstat(), bylo zasláno v roce 2010, ale daleko se nedostalo. V současnosti se některé systémy souborů pokoušejí provádět optimalizace pro tento druh zátěže, ale v jádře stále chybí obecné řešení. Za posledních několik let ale nebyl mezi vývojáří výraznější zájem o řešení problému.

    Za těchto okolností přišel Abhi se dvěma nezávislými řešeními, která předvádějí dva oddělené způsoby, jak problém řešit. Jeho cílem je získat zpětnou vazbu na oba a jakmile se ukáže, který z nich je oblíbenější, pak jej chce dostat do hlavní řady jádra.

    xgetdents()

    link

    První přístup je založený na systémovém volání xstat() od Davida Howellse z roku 2010. Přidává dvě nová systémová volání:

    int xstat(int dirfd, const char *filename, unsigned int flags,
              unsigned int mask, struct xstat *info);
    int fxstat(int fd, unsigned int flags, unsigned int mask, struct xstat *info);
    

    První podoba dohledá soubor podle jména, zatímco druhá vrací informace pro otevřený soubor podle popisovače. Pole flags mění fungování systémového volání; v tomto patchi se příliš nevyužívá. Zajímavější je mask, které jádru sděluje, jaké informace aplikace žádá. Dá se toho docela dost nastavit; mimo jiné XSTAT_MODE (pro práva souboru), XSTAT_UID (pro vlastníka), XSTAT_RDEV (na jakém úložišti soubor je, XSTAT_ATIME (poslední čas přístupu nebo XSTAT_INO (číslo uzlu). Pro získání všech dostupných informací lze použít XSTAT_ALL_STATS. V případě úspěchu bude struktura info naplněna vyžádanými údaji.

    Navrch tohoto přidal Abhi další systémové volání:

    int xgetdents(unsigned int fd, unsigned int flags, unsigned int mask,
                  void *buf, unsigned int count);
    

    fd zde představuje popisovač adresáře, který nás zajímá, a flags a mask fungují stejně jako výše (i když mask bylo rozšířeno tak, aby aplikace mohla žádat různé typy rozšířených atributů). Informace jsou vraceny v buf, což je prosté pole bajtů, a count obsahuje délku v bajtech. Volání xgetdents() se pokusí získat informace o více souborech v daném adresáři, než se buf zaplní.

    Data vracená v buf jsou poněkud složitá. Struktury nejvyšší úrovně definující tyto informace jsou:

    struct xdirent_blob {
    	unsigned int    xb_xattr_count;
    	char            xb_blob[1]; /* contains variable length data like
    				     * NULL-terminated name, xattrs etc */
    };
    
    struct linux_xdirent {
    	unsigned long        xd_ino;
    	char                 xd_type;
    	unsigned long        xd_off;
    	struct xstat         xd_stat;
    	unsigned long        xd_reclen;
    	struct xdirent_blob  xd_blob;
    };
    

    Dokumentace vraceného formátu je poněkud kusá. Ona vlastně žádná není, takže člověk je donucen si vše domyslet ze zdrojového kódu. Vypadá to, že informace o každém souboru budou vraceny ve struktuře linux_xdirent o proměnné délce. Název souboru je první věcí uloženou v xd_blob, následují pak informace o rozšířených atributech, pokud o toto bylo požádáno. Porozumění této struktuře nějakou chvíli potrvá, stejně tak rozebrání v uživatelském prostoru, ale má tu výhodu, že všechny informace mohou být shromážděny a vráceny v jediném systémovém volání.

    dirreadahead()

    link

    Alternativní přístup je poněkud jednodušší. Přidává jediné systémové volání:

    int dirreadahead(unsigned int fd, loff_t *offset, unsigned int count);
    

    Toto volání se pokusí zahájit čtení informací o souboru pro count souborů v adresáři vyjádřeném popisovačem fd, a to od pozice offset v adresáři. Hodnota offset bude aktualizována podle toho, o kolika souborech byly přečteny informace. Proto je možné použít vícero volání dirreadahead() pro procházení adresáře, zatímco jádro spravuje hodnotu offset.

    V tomto případě je nadále nutné volat getdents() a stat() pro zjištění potřebných informací. Mění se to, že systém souborů už snad bude mít potřebné údaje ve vnitřní cache, takže volání by měla být obsloužena rychle. Čtění informací o více souborech umožňuje provádění v dávkách; i když jsou data rozházená po fyzickém médiu, nezbytné I/O operace je možné přeuspořádat pro optimální provedení.

    Úvodní zpráva do patche o dvou částech zahrnuje výsledky benchmarků nad systémem souborů GFS2. Oba přístupy si vedly lépe nežli současná jádra při velké zátěži systémovými voláními getdents() a stat(). Možná vás to překvapí, ale dirreadahead() fungovalo mnohem lépe než xgetdents(). Tento výsledek může být důsledkem implementace xgetdents() v GFS2, ale ukazuje to, že i mnohem jednodušší přístup na bázi přednačítání může stát za zvážení.

    Myšlenka s přednačítáním vedla hnedle k otázce, jestli by jádro nemohlo provádět toto přednačítání automaticky, jak se děje u obyčejného I/O. Trond Myklebust poznamenal, že klient NFS se snaží detekovat zátěž, kde by tento typ přednačítání mohl být k užitku. Obecně je ale těžké takovou detekci dělat; v jádře není mezi voláními getdents() a stat() jasné spojení. Proto by alespoň prozatím mohl toto uživatelský prostor sdělovat napřímo. Mohlo by se k tomu použít některé ze dvou rozhraní zde popsaných, ale vypadá to, že jednoduchost dirreadahead() svědčí v jeho prospěch, i když nejsou k dispozici lepší benchmarky.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    19.8.2014 12:43 Jardík
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    int xgetdents(unsigned int fd, unsigned int flags, unsigned int mask, void *buf, unsigned int count);
    fd opravdu unsigned int?? Popisovač souboru vždy signed ne? Ale co je horší, count je unsigned int? Dopr*ele to zase navrhoval nějakej super programátor, co nezná size_t. Bohužel kernel je takovejhle blbin plnej.
    19.8.2014 13:26 Zdenek 'Mst. Spider' Sedlak | skóre: 37 | blog: xMstSpider
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    A proc to komentujes tady a ne na LWN?
    19.8.2014 13:43 Jardík
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    LWN nevím co je, asi nějakej web, ale nechodím tam. A většinou mi chcou na webech cpát registrace, sušenky a podobný zvěrstva, takže tak. A nechte mě bejt, si musím rejpnout. A teď jdu sníst nějaký ty sušenky k čajíčku, mám jich tu už nějak moc.
    19.8.2014 20:06 citanus | skóre: 10 | Cork (Ireland)
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů

    zde se nam formuje druhy BLEK!

    Petr Tomášek avatar 21.8.2014 10:51 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Zapomněl jsi na Zímu a jeho maniodepresivní výlevy...
    19.8.2014 13:34 chrono
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    xgetdents je len rozšírená verzia getdents, takže sťažovať sa treba na autorov funkcie getdents. ;)
    19.8.2014 14:37 Lukas
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Je jen skoda ze neexistuje absolutne nic co bys s tim mohl udelat krome komentare na abclinuxu.cz
    19.8.2014 15:57 koudy
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Opravit, udělat diff, zaslat patch a pak už se pouze hřát v láskyplné komunitě kernelových vývojářů a užívat si to, že jsem udělal ze světa lepší místo?

    Well nikdy to není tak jednoduché jak se zdá ;)
    19.8.2014 16:16 fe
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    No nevím, školy nemám, ale proč by měl být count (předpokládám že je to nějaký počet položek) záporný?
    19.8.2014 18:34 Tomáš
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Čéče, když ti nikdo nechce odpovědět, tak tě zkusím mystifikovat já. Některé funkce, které vracejí normálně nezáporné číslo, při neúspěchu vrátí záporné číslo. Myslím, že to hojně dělají funkce pro práci se znaky (písmeny). Nejspíš to count() dělá podobně. Je to spíš dědictví minulosti, kdy paměť byla k....sky druhá a a procesory pomalé, takže alokace každé proměnné a její předání do funkce byla drahá operace.
    19.8.2014 19:16 Roman Došek | skóre: 17 | blog: flare
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Ale ne, size_t je neznaménkový typ - to co se Jardíkovi nelíbí je fakt, že pro vracení velikostí polí/počtu položek/whatever by se měl používat size_t, protože ten podle standardu zaručuje, že zvládne tu velikost vždycky obsáhnout. Zatímco unsigned int nemá podle standardu pevnou velikost a tak se liší napříč platformami. (což může i size_t samozřejmě)

    Navíc použitím size_t dáváte najevo, že to je opravdu jen počet a nic jiného než počítání se to nepoužívá.
    26.8.2014 00:00 z
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Dáváte na najevo, že je to velikost.
    19.8.2014 21:28 dfgfcfg
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    nevim jake typy jsou dnes zvykem, ale nebylo by fajn se zbavit kokotin jako size_t nebo ***_t a mit jasnou velikost podle systemu int, long.....
    19.8.2014 23:49 mankind_boost | skóre: 4 | Hliněná chýše, 5482/3
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Buď rád za size_t, co teprv třeba LPCSTR na Woknech?
    19.8.2014 23:50 mankind_boost | skóre: 4 | Hliněná chýše, 5482/3
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    A co má bejt sakra LPCTSTR? :-D
    Conscript89 avatar 20.8.2014 11:33 Conscript89 | Brno
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Zni mi to madarsky.
    I can only show you the door. You're the one that has to walk through it.
    20.8.2014 11:47 mmmmario
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Long Pointer to Constant STRing, long protože Win16. typedef const char* LPCSTR;
    25.8.2014 23:59 z
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Spíš narážel na Tstring, ty Trubko
    20.8.2014 21:58 Vladimír Čunát | skóre: 18
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    size_t je integer o velikosti pointeru, coz se z principu musi lisit podle platformy. Kupodivu se to dost hodi, treba na delky poli, a ruzne pocty omezene pameti.
    21.8.2014 13:03 Jardík
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Nemáte tak docela pravdu pravdu, vůbec nemusí být o velikosti pointeru. Chcete-li integer ve velikosti pointeru, musíte se podívat jinam.
    20.8.2014 08:43 Ivan
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    < flame > Me se zase nelibi, ze tomu davaji prefix "x". Co budou delat, kdyz zjisti, ze to jeste neni uplne dobre? Na woknach kdyz meni syscall tak mu daji suffix "Ex", pak "Ex2", "Ex3", ... Proste pocitaji s tim, ze to nemusi byt dobre ani na podruhe, na potreti, ..< /flame >

    20.8.2014 09:12 R
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Vo Windows API je uplny bordel. Napr. CopyFile, CopyFile2, CopyFileEx.
    22.8.2014 19:51 aubi
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    JJ s CopyFileEx jsem si uzil... Koho by napadlo, ze to ve Win32s sice bude v API, ale nenaimplementovany! Ne aby udelali return CopyFile(...); a nadbytecny parametry zahodili, misto toho udelali return 0; a ja stravil tyden badanim, proc mi program nefunguje.
    20.8.2014 10:09 chrono
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Urobia to isté, čo pri iných systémových volaniach (a teda, bude to xgetdents2) :)
    20.8.2014 17:01 P_V
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Suffix je milionkrát lepší. Prefix dělá brajgl v nápovědě, která je podle abecedy :-)
    Petr Tomášek avatar 21.8.2014 10:46 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů

    Oprav si kurňa chyby!

    nedívno
    níčím
    Bedňa avatar 21.8.2014 15:38 Bedňa | skóre: 33 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Ak by rýchlosť výpisu bola pre niekoho kritická, tak odporúčam použiť ReiserFS. Nebenčmarkoval som to, ale to ani nieje treba, pretože je to desiatky možno stovky krát rýchlejsie než s ExtX.
    Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
    Max avatar 21.8.2014 15:53 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Pokud by byla pro někoho rychlost výpisu kritická, doporučuji SSD :)
    Zdar Max
    Měl jsem sen ... :(
    Bedňa avatar 21.8.2014 15:59 Bedňa | skóre: 33 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Maxi, ale to moje riešenie je zdarma ;)
    Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
    Max avatar 21.8.2014 20:24 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Ale jen napůl funkční. Osobně jsem donedávna používal reiserfs (hafo let a na jiných pc stále ještě používám), takže vím, jak rychlý je s ním výpis. Před cca 14 dny jsem přešel na SSD Crucial MX100 128GB, čistě jen na systém + naladil btrfs. Rychlost je neporovnatelná.
    Zdar Max
    Měl jsem sen ... :(
    Bedňa avatar 22.8.2014 07:10 Bedňa | skóre: 33 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Máš pravdu, práve tunajšie diskusie ma doviedli k tomu vyskúšať SSD a ten rozdiel je naozaj priepastný. V second job mám pár mašín na Reiseri sú tam tisíce súborov (nie systémových) a neplánujem to v najbližšej dobe migrovať, výkon je viac ako dostačujúci a prechod na SSD by bol nákladný. Čo ma tiež odrádza sú diskusie o tom ako oživiť zhebnuté SSD. Toto beriem ako najväčšie mínus SSD, pokiaľ sa bavíme o užívateľských dátach ktoré sa denno denne menia.
    Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
    Max avatar 22.8.2014 09:35 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Ve firemní sféře (a mělo by to tak být všude) se neřeší, jak získat data z rozbitého hdd, ale řeší se to, jak moc chce mít člověk aktuální backup a s jak velkou historií.
    Z tohoto hlediska tebou vznesené obavy postrádají smysl.
    Zdar Max
    Měl jsem sen ... :(
    pavlix avatar 22.8.2014 10:00 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Nevím, co je to ta firemní sféra, ale asi to nebude sféra, kam patří všechny firmy, že. Nicméně souhlasím, že by to tak mělo být.
    Bedňa avatar 22.8.2014 10:01 Bedňa | skóre: 33 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    výkon je viac ako dostačujúci a prechod na SSD by bol nákladný
    Toto je tiež dúfam dostačne Enterprise argument
    Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
    Max avatar 29.8.2014 00:34 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Nechápu, jak by to mělo souviset s mou připomínkou? Nikoho nenutím SSD používat, sám jej všude nepoužívám. Já jen nechápu, jak může někdo argumentovat tím, že nejdou z porouchaného SSD dostat data? To je snad fuk, ne? Pokud mi na datech záleží, tak mám zálohy, pokud ne, tak je nemám. Pokud mi na datech záleží a nemám zálohy, tak jsem idiot a s použitou technologií to nemá nic společného.
    Zdar Max
    Měl jsem sen ... :(
    Jendа avatar 23.8.2014 14:03 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Čo ma tiež odrádza sú diskusie o tom ako oživiť zhebnuté SSD.
    Tak rotační disky taky umírají. Umírají SSD nějak výrazně častěji?
    Bedňa avatar 23.8.2014 21:59 Bedňa | skóre: 33 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Len z placky idú tie dáta väčšinou vrátiť späť a nestojí to majland ako u SSD.
    Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
    23.8.2014 09:19 lertimir | skóre: 60 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    Nedal bys blogisek co to znamená "naladil btrfs pro SSD". Já mám v mount option "noatime,ssd,autodefrag,space_cache,discard".
    Conscript89 avatar 21.8.2014 23:44 Conscript89 | Brno
    Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 7. 2014: Rychlejší vypisování adresářů
    To mi s NFS nepomuze bohuzel, tam je to dost poznat, "ls --color=no" je mnohokrat rychlejsi nez "ls --color=yes". I taky to resolvovani symlinku nemusi byt nejlevnejsi.
    I can only show you the door. You're the one that has to walk through it.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.