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 11:00 | Komunita

Členové a příznivci spolku OpenAlt se pravidelně schází v Praze a Brně. Fotky z pražských srazů za uplynulý rok si můžete prohlédnout na stránkách spolku. Příští sraz se koná už zítra 19. ledna – tentokrát je tématem ergonomie ovládání počítače – tzn. klávesnice, myši a další zařízení. Také budete mít příležitost si prohlédnout pražský hackerspace Brmlab.

xkucf03 | Komentářů: 0
včera 21:55 | Komunita

Nadace pro svobodný software (FSF) oznámila aktualizaci seznamu prioritních oblastí (changelog), na které by se měli vývojáři a příznivci svobodného softwaru zaměřit. Jsou to například svobodný operační systém pro chytré telefony, hlasová a video komunikace nebo softwarový inteligentní osobní asistent.

Ladislav Hagara | Komentářů: 3
včera 16:44 | Nová verze

Byla vydána verze 2.0.0 knihovny pro vykreslování grafů v programovacím jazyce Python Matplotlib (Wikipedie, GitHub). Přehled novinek a galerie grafů na stránkách projektu.

Ladislav Hagara | Komentářů: 0
včera 15:33 | Komunita

V australském Hobartu probíhá tento týden konference linux.conf.au 2017. Na programu je celá řada zajímavých přednášek. Sledovat je lze online.

Ladislav Hagara | Komentářů: 0
včera 10:20 | Zajímavý článek

Pavel Tišnovský se v dvoudílném článku na MojeFedora.cz věnuje bitmapovým (rastrovým) grafickým editorům ve Fedoře. V prvním dílu se věnuje editorům MyPaint, MtPaint, Pinta, XPaint, Krita a GIMP. V pokračování pak editorům GNU Paint (gpaint), GrafX2, KolourPaint, KIconEdit a Tux Paint.

Ladislav Hagara | Komentářů: 1
16.1. 17:11 | Komunita

Byl proveden bezpečnostní audit svobodného IMAP a POP3 serveru Dovecot (Wikipedie). Audit byl zaplacen z programu Mozilla Secure Open Source a provedla jej společnost Cure53. Společnost Cure53 byla velice spokojena s kvalitou zdrojových kódu. V závěrečné zprávě (pdf) jsou zmíněny pouze 3 drobné a v upstreamu již opravené bezpečnostní chyby.

Ladislav Hagara | Komentářů: 0
16.1. 15:30 | IT novinky

Nadace Raspberry Pi představila na svém blogu Raspberry Pi Compute Module 3 (CM3 a CM3L), tj. zmenšené Raspberry Pi vhodné nejenom pro průmyslové využití. Jedná se o nástupce Raspberry Pi Compute Module (CM1) představeného v dubnu 2014. Nový CM3 vychází z Raspberry Pi 3 a má tedy dvakrát více paměti a desetkrát větší výkon než CM1. Verze CM3L (Lite) je dodávána bez 4 GB eMMC flash paměti. Uživatel si může připojit svou vlastní. Představena byla

… více »
Ladislav Hagara | Komentářů: 1
16.1. 01:23 | Nová verze

Oficiálně bylo oznámeno vydání verze 3.0 multiplatformního balíku svobodných kancelářských a grafických aplikací Calligra (Wikipedie). Větev 3 je postavena na KDE Frameworks 5 a Qt 5. Krita se osamostatnila. Z balíku byly dále odstraněny aplikace Author, Brainstorm, Flow a Stage. U Flow a Stage se předpokládá jejich návrat v některé z budoucích verzí Calligry.

Ladislav Hagara | Komentářů: 7
15.1. 15:25 | Nová verze

Bylo oznámeno vydání první RC (release candidate) verze instalátoru pro Debian 9 s kódovým názvem Stretch. Odloženo bylo sloučení /usr jako výchozí nastavení v debootstrap. Vydán byl také Debian 8.7, tj. sedmá opravná verze Debianu 8 s kódovým názvem Jessie.

Ladislav Hagara | Komentářů: 6
15.1. 13:37 | Zajímavý projekt

1. ledna byl představen projekt Liri (GitHub). Jedná se o spojení projektů Hawaii, Papyros a původního projektu Liri s cílem vyvíjet operační systém (linuxovou distribuci) a aplikace s moderním designem a funkcemi. Včera byl představen Fluid 0.9.0 a také Vibe 0.9.0. Jedná se o toolkit a knihovnu pro vývoj multiplatformních a responzivních aplikací podporující Material Design (Wikipedie) a volitelně také Microsoft Design Language (designový jazyk Microsoft) [reddit].

Ladislav Hagara | Komentářů: 8
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (10%)
 (2%)
 (74%)
 (3%)
 (10%)
Celkem 309 hlasů
 Komentářů: 24, poslední včera 10:14
    Rozcestník
    Reklama

    Dotaz: Pomalé rm (ext4, qnap)

    xvasek avatar 19.5.2015 15:44 xvasek | skóre: 21 | blog: | Zlín
    Pomalé rm (ext4, qnap)
    Přečteno: 585×
    Ahoj lidi,

    to jsem z toho mýdlo s jelenem. Mám qnap NAS (TS-110, což je celkem entry level plečka, ale je "jen" na zálohy), na něj se odlévají velké soubory záloh vmware přes NFS - to v zásadě funguje.

    Problém který řeším už docela dlouho, je rychlost mazání těchto záloh. Jsou to v podsatě pár (desítek) GB velké děravé soubory, které se před vytvořením nové zálohy vždy mažou. Smazání ale trvá hrozně dlouho, jeden takový soubor se maže i cca 10 minut. Původně jsem si myslel, že je problém v NFS, ale pak jsem se zkusil přihlásit přes ssh na ten NAS - běží tam taková trochu zvláštní distribuce linuxu s busyboxem - a smazat to pomocí rm. I to samotné rm na jeden takový velký soubor trvá stejně dlouho - klidně 10 minut. V "top" se mi vypisuje, že rm běží na procesoru (proč? más pustit unlink() a čekat) a co mi přijde nejzajímavější, tak volné místo (df -h) přibývá "postupně", rychlostí cca 100MB/s, což mi přijde cca jako rychlost toho disku. Jako by si to místo musel uvolnit přepsáním celého toho souboru. Přitom tam žádnou takovou featuru nemám, není to šifrované, security jsem prolezl a nikde není nic takového zapnutého - jakože wipe souborů nebo tak něco... rm samotné je link na busybox, což je správně. FS je ext4.

    Nemáte někdo nějaký tip?

    Řešení dotazu:


    Odpovědi

    19.5.2015 15:58 pavels
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    co zkusit strace -p <pid> a zjistit, co vlastne dela?
    19.5.2015 16:18 luv
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    jojo, z popisu to vypada na nejakou zvlastni implementaci rm
    19.5.2015 22:58 trubicoid
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    vlastni rm? co rika which rm? mas normalni /bin/rm?

    pripadne zkus udelat link rm na /bin/busybox, ten by se mel chovat normalne, asi

    trebas ln -s /bin/busybox /usr/local/bin/rm

    /usr/local/bin/rm ...
    19.5.2015 23:00 trubicoid
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    ajo, rikas ze rm je link na busybox, tak nic
    19.5.2015 23:08 trubicoid
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    a proc ta zaloha je derava? je skutecne sparse? jak presne to delas? cp --sparse=always ?

    jinak mi napada, ze se dlouho maze kvuli tomu, ze je sparse a tim padem fragmentovana, co e4defrag?
    xvasek avatar 20.5.2015 10:29 xvasek | skóre: 21 | blog: | Zlín
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    Děravá je, protože ji tak vmware vytvoří, protože thin provisioning. Ony mají sice tak 60 - 200GB, ale na disku bývá reálně jenom cca polovina, podle obsazení disku ve VM. Jinak já tu zálohu nekopíruju, vmware ji tam rovnou vytvoří, technicky vzato je to plný snapshot, který si "odplivne" server (a zapomene na něj). Že je děravý mi nevadí, to je naopak plus, navíc podle mého chápání děravosti by to při mazání mělo spíš pomoct, než brzdit, protože je potřeba odalokovat jenom polovinu místa. e4defrag vidím poprvé, zkusím, mohlo by to být ono, taky jsem nad fragmentací přemýšlel. Druhou možnost vidím pak ve znovuvytvoření FS, ale moc se mi do toho nechce, protože jsou tam i jiná data a nemám je kam dát.
    20.5.2015 17:10 luv | skóre: 16 | blog: luv
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    nedivil bych se kdyby "ta trochu zvlastni distribuce" mela v sobe upraveny busybox
    java? shapes and colors ... with an angle grinder!
    20.5.2015 20:43 nobody
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    pokud se to chova stejne i vzdalene pres nfs, kdy maze rm z coreutils, tak asi nebude problem s rm v busyboxu na serveru ;)
    21.5.2015 21:32 luv | skóre: 16 | blog: luv
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    Pravda. Takze upraveny busybox a nfs server na tom NASu? ;)

    S jakyma optionama je ten filesystem primountovany?
    java? shapes and colors ... with an angle grinder!
    22.5.2015 09:16 R
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    Alebo upraveny kernel.
    22.5.2015 11:05 luv | skóre: 16 | blog: luv
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    A na to bychom prisli pokud bychom videli vystup z strace, po kterem se pavel ptal v prvni odpovedi.
    java? shapes and colors ... with an angle grinder!
    xvasek avatar 22.5.2015 12:55 xvasek | skóre: 21 | blog: | Zlín
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    Strace tam není, ani v balíku, musel bych ho nějak zkompilovat. Zkusím.
    xvasek avatar 22.5.2015 13:18 xvasek | skóre: 21 | blog: | Zlín
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    S jakyma optionama je ten filesystem primountovany?
    Implicitně takto:

    /dev/sda3 on /share/HDA_DATA type ext4 (rw,usrjquota=aquota.user,jqfmt=vfsv0,user_xattr,data=ordered,nodelalloc,noacl)

    Zkoušel jsem to remountnout s delalloc, ale žádný rozdíl. Zajímavé je, že pár GB velké soubory (typu například .mkv :-) ) to smaže v řádu maximálně jednotek sekund, ale mazání tady těch vmware záloh je pomalé, i když jsou relativně stejně velké (+- 4GB).

    Začínám podezírat ext4 vs děravost souborů.
    xvasek avatar 22.5.2015 13:35 xvasek | skóre: 21 | blog: | Zlín
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    Ha, začínám hledat nějaký "secure delete" atribut, jenž sice nemá být implementován (a prý nejde přenášet přes NFS), ale čert ví. Jenom tam na to nejsou příkazy.
    xvasek avatar 22.5.2015 14:12 xvasek | skóre: 21 | blog: | Zlín
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    Tak zpátky na stromy, atribut "safe delete" nastaven není.
    22.5.2015 14:40 pavels
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    tak co vypsal ten strace?
    22.5.2015 14:53 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    Bylo by celkem překvapivé, kdyby při mazání jednoho souboru ukázal něco jiného než volání unlink() nebo unlinkat().
    xvasek avatar 22.5.2015 14:56 xvasek | skóre: 21 | blog: | Zlín
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    Napřed takový ten bordel jako obvykle a nakonec:
    lstat64("stodulkovi.cz-flat.vmdk", {st_mode=S_IFREG|0600, st_size=64424509440, ...}) = 0
    access("stodulkovi.cz-flat.vmdk", W_OK) = 0
    unlink("stodulkovi.cz-flat.vmdk"
    
    ...a v tom unlinku visí ten dlouhý čas. Pak to uklidí a končí. Takže nic zvláštního.
    19.5.2015 17:35 mimi.vx | skóre: 37 | blog: Mimi.VX | Praha
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)

    pokud tam mas 'find' tak to zkus smazat s nim find co --delete

    USE="-gnome -kde";turris
    20.5.2015 21:16 pave.
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    Nebylo by rychlejsi "echo > filename; rm filename" ?
    xvasek avatar 22.5.2015 12:57 xvasek | skóre: 21 | blog: | Zlín
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    Díky za pokus, ale echo > filename běží taky věčnost. :-/
    22.5.2015 08:59 lertimir | skóre: 59 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    Jak je firmware aktuální. V bugfixes z lo%nského roku (prosinec, září) mají i takového hlášky
    - The NAS will reboot automatically after large files (larger than 850G) are removed in File Station.
    - It takes a very long time to move a large number of folders and files to another shared folder on the same NAS via File Station. 
    - The Turbo NAS will occasionally reboot when transmitting large files via CIFS/SMB.
    - The Turbo NAS will occasionally reboot when you backup files to an external hard drive.
    
    Takže mě jejich implementace připadá dost děravá. A zkusil bych jejich forum.
    xvasek avatar 22.5.2015 12:59 xvasek | skóre: 21 | blog: | Zlín
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    Firmware mám aktuální. Nicméně tady ty bugy se týkají vesměs jejich utilit, se kterýma já nepracuju. A reboot mi nenastává, takže problém bude asi někde jinde.
    Řešení 2× (luv, xvasek (tazatel))
    22.5.2015 14:06 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    V "top" se mi vypisuje, že rm běží na procesoru (proč? más pustit unlink() a čekat)

    To, že běží syscall v jádře, se pořád prezentuje jako stav "R", teprve pokud by spal, bude to buď "S" (interruptible) nebo "D" (uninterruptible). Nanejvýš hrozí, že zakročí soft lockup detector, pokud by v tom jádře běžel beze spánku moc dlouho.

    Jinak mazání dlouhých souborů je na ext2/3/4 opravdu pomalé, což je dáno implementací pomocí indirect, double indirect a triple indirect bloků. Ale 10 minut na desítky GB je opravdu hodně, leda snad při kombinaci pomalého procesoru, pomalého disku a málo paměti.

    xvasek avatar 22.5.2015 14:34 xvasek | skóre: 21 | blog: | Zlín
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    [...] leda snad při kombinaci pomalého procesoru, pomalého disku a málo paměti.
    To tam všechno je: Marvel ARM 800MHz (jednojádro tuším), 256MB RAM a disk je taky jakýsi "green". Nicméně pořád nemám uspokojivou odpověď, proč je takový rozdíl mazat zálohu malého image z vmware o velikosti 4GB (trvá cca 40s, tzn. oněch ~100MB/s) a podobně velký jiný soubor např. Rebelka.mkv (smaže za méně než 1s). Jediný rozdíl mezi těmi soubory je v tom, že vmware vznikl přes NFS a je děravý.
    22.5.2015 14:51 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    Tím "děravý" myslíte sparse file nebo to, že je fragmentovaný? Rozdíl může být třeba v tom, že na ext4 je možné využít extents, čímž by odpadl problém s procházením stromové struktury indirect bloků. Ten propastný rozdíl pak může být způsoben tím, že počet "ušpiněných" bloků u jednoho souboru nevynutí okamžitý flush, zatímco u druhého ano. Ve výsledku tak poměr počtu bloků, které je potřeba zapsat, nemusí být tak výrazný, ale poměr časů "než rm skončí" ano.
    xvasek avatar 22.5.2015 15:05 xvasek | skóre: 21 | blog: | Zlín
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    Ano, myslím sparse. Co je "extents" netuším, ale je to tam zapnuté a aktivní dle lsattr. Dále tomu vysvětlení moc nerozumím (resp. nechápu, proč by to mělo být jiné - podle mého je mazat sparse file ve všech směrech jednodušší), ale zvažuju přeformátování na ext3, mám nějakou šanci, že to pomůže?
    22.5.2015 15:10 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    Těžko - extents můžou pomoci, pokud se při alokaci místa pro soubor použijí. Takže přechodem na ext3, který je neumí, sice možná docílíte toho, že čas potřebný ke smazání obou suborů bude podobný, ale tím opačným způsobem, než byste chtěl.
    xvasek avatar 22.5.2015 15:27 xvasek | skóre: 21 | blog: | Zlín
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    :-) Hm, díky. Už to chápu, ale časem tomu dám asi šanci. Pořád mi totiž připadá, že tam probíhá něco jako safe erase (nějakou chybou?), které ext3 vůbec neumí, takže bych měl aspoň jistotu, že neprobíhá.

    Ale stejně je mi divné, že tento problém jsem nikde na netu popsaný nenašel, přestože na qnap zálohuje přes ghettoVCB z vmware kde kdo a já nemám nikde v tom setupu nic nestandardního - ani na vmware, ani na qnapu. Nebo na ty zálohy použiju RPI s raspbianem - tam je aspoň standardní systém.
    22.5.2015 16:33 ET
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    co smart? obcas disky "drhnou", kdyz je jim spatne
    xvasek avatar 22.5.2015 16:37 xvasek | skóre: 21 | blog: | Zlín
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    Smart condition je "Good", to už jsem se díval, než jsem vůbec začal psát ten dotaz.
    22.5.2015 16:43 ET
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    mno, jeste bych (pro jistotu) mrknul na dmesg ;-)
    xvasek avatar 22.5.2015 16:48 xvasek | skóre: 21 | blog: | Zlín
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    To tam psalo nějaké chyby ohledně ext4, ale update firmware (resp. spíš software) to opravil. Pak jsem to samozřejmě fsckoval.
    xvasek avatar 22.5.2015 16:45 xvasek | skóre: 21 | blog: | Zlín
    Rozbalit Rozbalit vše Re: Pomalé rm (ext4, qnap)
    Jinak mazání dlouhých souborů je na ext2/3/4 opravdu pomalé, což je dáno implementací pomocí indirect, double indirect a triple indirect bloků. Ale 10 minut na desítky GB je opravdu hodně, leda snad při kombinaci pomalého procesoru, pomalého disku a málo paměti.
    Nakonec beru toto vysvětlení jako řešení, v zásadě je to opravdu plečka - ARMv5/800MHz. Pro řešení svého problému jsem přidal do crontabu na tom NASu řádek, který dělá "echo > soubor" do těch image, které jsou starší, než 6 dnů, což bude trvat asi hodinu denně, ale pak to zálohovací script z vmware při rotaci záloh bez problému během pikosekundy smaže (přes NFS) a netimeoutuje - to byl původní problém. Aspoň se ten NAS nebude furt flákat. :-)

    Založit nové vláknoNahoru

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

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