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 08:00 | Zajímavý software

Facebook uvolnil svou platformu pro detekci objektů s názvem Detectron. Detectron je naprogramován v Pythonu a využívá framework pro deep learning Caffe2. Zdrojové kódy Detectronu jsou k dispozici na GitHubu pod licencí Apache 2.0.

Ladislav Hagara | Komentářů: 0
dnes 03:00 | Komunita

Bylo spuštěno hlasování o přednáškách a workshopech pro letošní InstallFest, jenž proběhne o víkendu 3. a 4. března 2018 v Praze na Karlově náměstí 13. Hlasovat lze do pondělí 29. ledna 2018.

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

Projekt Document Liberation, jehož cílem je vývoj knihoven pro zpřístupnění (osvobození) dokumentů vytvořených v proprietárních nebo již nepodporovaných formátech, oznámil vydání 5 nových nebo vylepšených knihoven. Jedná se o knihovnu libe-book pro export dokumentů ve formátu EPUB3 a knihovny libabw, libmspub, libpagemaker a libqxp pro import dokumentů ve formátech AbiWord, MS Publisher, PageMaker a QuarkXPress.

Ladislav Hagara | Komentářů: 0
dnes 01:00 | Komunita

LWN.net, původně Linux Weekly News, slaví 20 let. První číslo vyšlo 22. ledna 1998. Psalo se o devfs, o 2 GB omezení velikosti souborů na souborovém systému ext2 nebo o renderování scén ve filmu Titanic na Linuxu na procesorech Alpha. Aktuální vývojové linuxové jádro bylo 2.1.79. LWN.net je zcela závislé na předplatitelích. Předplatné na měsíc stojí 7 dolarů. Články na LWN.net jsou týden od vydání k dispozici pouze předplatitelům. Následně jsou uvolněny všem pod licencí CC-BY-SA.

Ladislav Hagara | Komentářů: 0
včera 15:22 | Pozvánky

V sobotu 24. 2. se uskuteční již 5. ročník největší české WordPress konference – WordCamp Praha 2018. Pražský WordCamp bude rozdělen na dva proudy – pro uživatele a pro vývojáře. Je naplánováno 10 přednášek, 6 workshopů, 6 případových studií, Happines Bar a spousty příležitostí pro networking. V neděli se bude dále konat Contributing Day, kde se každý bude moci aktivně zapojit do překladu, či plánování dalších meetupů. Je připraveno 450

… více »
smíťa | Komentářů: 0
včera 05:55 | Komunita

Linus Torvalds oznámil vydání Linuxu 4.15-rc9. Po vydání stabilní verze Linuxu se přibližně na 2 týdny otevře začleňovací okno. To se uzavře vydáním verze rc1. Po týdnech následují další rc verze. Obvykle týden po vydání verze rc7 nebo rc8 následuje vydání nové stabilní verze Linuxu. Verze rc9 byla naposledy vydána před více než 6 lety, 4. října 2011. Jednalo se o Linux 3.1. Tenkrát následovala ještě verze rc10.

Ladislav Hagara | Komentářů: 15
21.1. 21:55 | Zajímavý článek

Greg Kroah-Hartman se v příspěvku na svém blogu věnuje aktuálnímu stavu řešení bezpečnostních chyb Meltdown a Spectre v Linuxu. Jak je na tom Váš Linux? Stačí spustit příkaz "grep . /sys/devices/system/cpu/vulnerabilities/*". Pro více informací lze doporučit Spectre & Meltdown Checker.

Ladislav Hagara | Komentářů: 46
19.1. 18:55 | Komunita

NHSbuntu (Joinup, prezentace) měla být z Ubuntu vycházející linuxová distribuce přizpůsobená pro potřeby britské Národní zdravotní služby (NHS). NHS se název nelíbil, nejednalo se o oficiální projekt NHS, a proto bylo NHSbuntu v září loňského roku přejmenováno na NHoS. Vývojáři NHoS tento týden oznámili, že NHS se nelíbí ani název NHoS a už nemají sílu na další přejmenování a pokračování v projektu. Dodávají, že několik jednání s vedením

… více »
Ladislav Hagara | Komentářů: 7
19.1. 18:44 | Pozvánky

Koncem ledna, 29. 1. 2018 od 17 do 20 hodin se v Akademii CZ.NIC uskuteční večer s Turrisem.

Co bude na programu?… více »
Miška | Komentářů: 19
19.1. 18:33 | Pozvánky

Na tri dni sa hlavné mesto Slovenska po tretíkrát zmení na miesto s najväčšou koncentráciou profesionálnych programátorov, systémových administrátorov, učiteľov informatiky aj technologických nadšencov. Hlavným lákadlom bude konferencia PyCon SK 2018, určená záujemcom o Python, jeden z najpopulárnejších programovacích jazykov na svete.

… více »
RicCo386 | Komentářů: 1
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (7%)
 (1%)
 (1%)
 (1%)
 (77%)
 (13%)
Celkem 1375 hlasů
 Komentářů: 53, poslední 17.1. 16:55
    Rozcestník

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

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

    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: 11 | 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: 5 | 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: 5 | 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: 19
    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: 34 | 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.
    KERNEL ULTRAS video channel >>>
    Max avatar 21.8.2014 15:53 Max | skóre: 66 | 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: 34 | 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 ;)
    KERNEL ULTRAS video channel >>>
    Max avatar 21.8.2014 20:24 Max | skóre: 66 | 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: 34 | 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.
    KERNEL ULTRAS video channel >>>
    Max avatar 22.8.2014 09:35 Max | skóre: 66 | 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.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    Bedňa avatar 22.8.2014 10:01 Bedňa | skóre: 34 | 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
    KERNEL ULTRAS video channel >>>
    Max avatar 29.8.2014 00:34 Max | skóre: 66 | 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?
    I don't believe in the concept of personal property that isn't mine.
    Bedňa avatar 23.8.2014 21:59 Bedňa | skóre: 34 | 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.
    KERNEL ULTRAS video channel >>>
    23.8.2014 09:19 lertimir | skóre: 61 | 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.