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:11 | Pozvánky

Spolek OpenAlt zve příznivce otevřeného přístupu na 142. brněnský sraz, který proběhne v pátek 21. července od 18:00 hodin ve Sport Centru Srbská (Srbská 4). Od 19:00 je pro zájemce zamluveno hřiště na plážový volejbal.

Ladislav Hagara | Komentářů: 0
dnes 12:34 | Bezpečnostní upozornění

V GNOME Soubory, původně Nautilus, konkrétně v generování náhledů exe, msi, dll a lnk souborů byla nalezena a opravena bezpečnostní chyba CVE-2017-11421 s názvem Bad Taste. Při otevření složky obsahující tyto soubory může být spuštěn VBScript obsažen v názvech těchto souborů.

Ladislav Hagara | Komentářů: 1
dnes 11:00 | Bezpečnostní upozornění

Společnost Oracle vydala čtvrtletní bezpečnostní aktualizaci svých softwarových produktů (CPU, Critical Patch Update). Opraveno bylo celkově 308 bezpečnostních chyb. V Oracle Java SE je například opraveno 32 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 28 z nich. V Oracle MySQL je opraveno 30 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 9 z nich.

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

Mark Krenz, známý svým twitterovým účtem @climagic (Command Line Magic), kde ukazuje, co vše a jak lze dělat v příkazovém řádku, přednášel včera v Praze. Záznam přednášky je k dispozici na YouTube.

Ladislav Hagara | Komentářů: 0
včera 10:00 | Nová verze

Microsoft vydal Skype pro Linux ve verzi 5.4 Beta. Nejnovější Skype pro Linux je postaven na frameworku Electron 1.7.4 a přináší skupinové videohovory.

Ladislav Hagara | Komentářů: 11
včera 06:00 | Nová verze

Werner Koch, zakladatel a hlavní vývojář GnuPG, oznámil vydání verze 1.8.0 svobodné kryptografické knihovny Libgcrypt. Jedná se o první stabilní verzi nové řady 1.8. Ta je API i ABI kompatibilní s řadou 1.7. Z novinek vývojáři zdůrazňují podporu kryptografických hašovacích funkcí Blake2 (Wikpedie), šifrovací mód XTS nebo zvýšení výkonu na architektuře ARM.

Ladislav Hagara | Komentářů: 0
18.7. 15:55 | Zajímavý projekt

Stefan Vorkoetter představil na svých stránkách DIY tablet s Raspberry Pi 3 Model B. Z Raspberry Pi odstranil USB porty, ethernetový port i GPIO konektor. Použil oficiální sedmipalcový dotykový displej s rozlišením 800x480 pixelů. Hmotnost tabletu je 484  g.

Ladislav Hagara | Komentářů: 6
18.7. 06:00 | Zajímavý projekt

Podpořit vývoj otevřených technologií pro rozpoznávaní řeči lze na stránkách Common Voice. Jedná se o projekt Mozilly, jehož prvním cílem je nahrání a následné zveřejnění pod open source licencí 10 000 hodin záznamů řeči. Pomoci může kdokoli. Stačí na stránkách projektu do mikrofonu přečíst napsaný text nebo si nechat přehrávat již nahrané záznamy a určovat, zda napsaným textům odpovídají. Podrobnosti v často kladených otázkách (FAQ).

Ladislav Hagara | Komentářů: 4
18.7. 05:00 | IT novinky

Do pátku probíhá v Praze IETF 99, tj. 99. setkání organizace Internet Engineering Task Force (IETF) odpovědné za tvorbu internetových standardů RFC (Request for Comments). Vybrané přednášky a jednání lze sledovat online. Záznamy jsou k dispozici na YouTube. Těsně před setkáním bylo vydáno RFC 8200 nahrazující RFC 2460 a po více než 18 letech standardizující IPv6 (STD 86).

Ladislav Hagara | Komentářů: 0
18.7. 00:33 | Nová verze

Byl spuštěn další Humble Book Bundle. Tentokrát jsou v nabídce elektronické knihy věnované kybernetické bezpečnosti od vydavatelství Wiley. Všech 14 knih lze koupit za 15 dolarů.

Ladislav Hagara | Komentářů: 0
Chystáte se pořídit CPU AMD Ryzen?
 (7%)
 (31%)
 (1%)
 (10%)
 (43%)
 (8%)
Celkem 1023 hlasů
 Komentářů: 65, poslední 1.6. 19:16
    Rozcestník

    Dotaz: Prenos velkeho mnozstvi souboru

    12.5.2010 20:26 methuz | skóre: 7 | blog: robutek
    Prenos velkeho mnozstvi souboru
    Přečteno: 1049×

    Zdravim, mam tu pomerne zapeklite zadani ukolu:

    1) mejme dva servery spojene gigabitovou linkou

    2) kazdy ze serveru je pripojen ke svemu vlastnimu SANu pomoci HBAcek

    3) prvni ze serveru ma ze sveho SANu namountovanych 5 filesystemu (vsechno je ext3) ktere dohromady obsahuji cca 100 000 souboru o celkove velikosti 150GB

    4) druhy ze serveru ma namountovany velky LUN ze SANu - mista je tedy dost

    a otazka zni: jak dostat data z prvniho SANu na druhy pokud je na transfer dat vymezena 1 hodina? ;) (cela akce ma za ukol pouze zabackupovat data z prvniho storage, tudiz zachovani adresarove struktury, prav atd je podminkou)

    Moznosti je relativne hooodne. Jde jen o to najit tu nejjednodussi a hlavne nejrychlejsi. Za kazdy napad predem diky!

    The only problem with troubleshooting is that sometimes trouble shoots back ..

    Řešení dotazu:


    Odpovědi

    12.5.2010 20:39 Carth_Onasi
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Otazka: O jake soubory jde -> pomer a moznost komprimace. Smis komprimovat a jestli to pomuze?
    12.5.2010 20:51 methuz | skóre: 7 | blog: robutek
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    male binarni soubory. komprimovat lze ale je to vcelku zbytecny - misto ani rychlost site neni problem. problem je tahani velkyho mnozstvi souboru vs. tahani jednoho velkyho. prijde mi ze nejlepsi varianta je asi tar+nfs ale mozna nekoho napadne neco lepsiho
    The only problem with troubleshooting is that sometimes trouble shoots back ..
    12.5.2010 20:41 karlw
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    tar rulez
    13.5.2010 11:45 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Problém je, že tar nezachovává (přinejmenším) ACL.
    13.5.2010 16:34 karlw
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    ale ale:

    --acls
    13.5.2010 17:31 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru

    A jaká verze? U mne (OpenSuSE 11.2) to dopadne takto:

    mike@lion:~/work/foto/canon> tar -cf out.tar --acls out
    tar: neznámý přepínač `--acls'
    Try `tar --help' or `tar --usage' for more information.
    mike@lion:~/work/foto/canon> tar --version
    tar (GNU tar) 1.21
    ...
    
    14.5.2010 11:11 karlw
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    $  tar --acls --selinux -cf cosi.tgz blahblah.txt
    $  tar --version
    tar (GNU tar) 1.22
    Copyright (C) 2009 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html.
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
    
    Written by John Gilmore and Jay Fenlason.
    $ cat /etc/issue
    Fedora release 11 (Leonidas)
    
    michich avatar 14.5.2010 11:19 michich | skóre: 51 | blog: ohrivane_parky
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Podporu pro archivování rozšířených atributů (včetně ACL a SELinux kontextů) přidává do taru ve Fedoře patch. Nevím, proč to pořád ještě není přímo v GNU tar.
    14.5.2010 12:53 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru

    Mám podezření, že vývoj (nebo aspoň údržba) GNU tar je poněkud problematický(á). Matně si např. vzpomínám na překvapivě dlouho přetrvávající bug v parsování parametru -L, který měly snad všechny distribuce opravený, ale v mainstreamu pořád zůstávával.

    Nemůže tam být nějaký problém s kompatibilitou? Zvládne neopatchovaný tar správně rozbalit archiv, ve kterém jsou ACL a EA?

    14.5.2010 14:50 karlw
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Příloha:
    Jelikož jsem RH-centristický, tak mne to nepálí, ale můžeme vyzkoušet. Přikládám soubor test.tgz, který obsahuje test.txt uživatele 500:500, a má přes ACL povolený -w- pro uživatele nobody.

    Pokud ho roztaruju na fs s mount option (rw,acl), tak se atribut pro nobody ukáže. Pokud ho roztaruju příkazem "tar --no-xattrs -xzf test.tgz" nebo pokud nemám acl povoleny na fs, pak tam ten atribut pro noname není.
    $  tar -xzf test.tgz 
    $  getfacl test.txt 
    # file: test.txt
    # owner: karlw
    # group: karlw
    user::rw-
    user:nobody:-w-
    group::rw-
    mask::rw-
    other::r--
    
    
    Napište, jak jste s tím pochodili
    14.5.2010 16:43 marbu | skóre: 28 | blog: hromada | Brno
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Zdá se, že neopatchovaný tar prostě acl atributy ignoruje:
    $ tar -xzf test.tgz
    tar: Ignoruje se neznámé klíčové slovo „SCHILY.acl.access“ rozšířené hlavičky
    $ getfacl test.txt 
    # file: test.txt
    # owner: martin
    # group: users
    user::rw-
    group::r--
    other::r--
    
    
    I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
    14.5.2010 17:03 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru

    Chová se to rozumně, ignoruje to a vypíše hlášku

      tar: Ignoring unknown extended header keyword `SCHILY.acl.access'
    
    15.5.2010 11:15 EE
    Rozbalit Rozbalit vše --xattr-acl v GNU tar
    Podporu pro archivování rozšířených atributů (včetně ACL a SELinux kontextů) přidává do taru ve Fedoře patch. Nevím, proč to pořád ještě není přímo v GNU tar
    Zaujala me ta otazka, tak jsem se po tom podival. Nove verze GNU taru vychazi v poslednich 4 letech zhruba jednou za rok.

    Podle poslednich zprav jsou ty patche soucasti distribuovaneho tarballu, ale nelinkuji se, protoze ani po 4 letech (!) jeste nemaji produkcni kvalitu. O tom ostatne svedci ty uvedene priklady tady (#31 a #32), kde se klicove slovo rozsirene hlavicky vypisuje jako SCHILY.acl.access, pojmenovane podle autora (Jörga Schillinga) predchoziho formatu rozsirene hlavicky ([1], {2]). Tedy nepouziva to hlavicku ve formatu POSIX.1-2001, ale starsi 'star'.

    Stejne by ale podle POSIXu snad uz nemel byt tar pouzivan ([1]). Misto toho je v POSIXu obsazen program a predepsan format pax. GNU tar se prave snazi implementovat ten tvar paxovych hlavicek, jak ho predepisuje POSIX.

    Podle Jorga Schillinga ([1]) ale POSIX zadny standard ACL neobsahuje (Unix ACL != POSIX ACL ??). Predpokladam pak tedy, ze obsahuje alespon zpusob, jak je zaznamenat do archivu.

    Priznam se, ze neni jednoduche se v tom zorientovat. Nez jsem se zacetl do vsech tech podrobnosti o tar-u, tak jsem nemel ani poneti, kolik je za tim vedy.

    Abych to ale nejak shrnul:
    • Linux pouziva nejakou nestandardni (a udajne dost jednoduchou) implementaci ACL
    • zatim existuje jen navrh POSIXoveho standardu pro ACL (pouziva ho napriklad NFS4 a uz ho maji implementovane in Windows ve NTFS). Snad to pochazi ze Solarisu??
    • archivni program star (slovni hratka na s-tar, chapete?), ktery take vytvari soubory .tar, implementoval jakysi prechodny format pro zaznam Linuxovych ACL. Ten format je ten "Schily.xattr..." a je to rozsireni starsiho typu hlavicky.
    • GNU tar zatim neumi v produkcni kvalite nejnovejsi rozsiritelne hlavicky ve formatu pax, jak predepisuje POSIX pro archivy a proto obsahuje (rovnez neaktivovanou) implementaci toho 'star' formatu pro ukladani Linuxovych ACL
    To je teda zmatek, co? Snad jsem to pochopil vsechno vice mene spravne. Jestli jsem siril nejake vyrazne bludy, tak se omlouvam.
    15.5.2010 12:02 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: --xattr-acl v GNU tar
    Linux pouziva nejakou nestandardni (a udajne dost jednoduchou) implementaci ACL

    Nebyl by k tomuto tvrzení nějaký zdroj?

    15.5.2010 20:24 EE
    Rozbalit Rozbalit vše ACL standard v Linuxu
    Po opetovnem nekolikerem precteni odkazu, co jsem uvedl vyse, odvolavam svoje tvrzeni, ze Linux pouziva jednoduchou implementaci ACL. I kdyz je ta implementace technicky vzato nestandardni, tak stejny format pouzivaji vsechny rozumne OS, protoze zadny standard pro ACL proste zatim neexistuje.

    Asi nejlepsi povidani o tom ma Wikipedie (aktualni ceska verze ma trosku vice informaci o neprijatem standardu).
    15.5.2010 21:11 VSi | skóre: 28
    Rozbalit Rozbalit vše Re: ACL standard v Linuxu
    Z praktického pohledu bych to shrnul následovně, běžně se používají:

    - tzv. POSIX.1e ACL, která ovšem už nejsou součástí POSIX. To je implementace, kterou má např. ext3 nebo xfs připojené s volbou acl.

    - tzv. NFSv4 ACL, které mají řekl bych největší budoucnost. Specifikace je součástí NFS verze 4. Hlavně jsou plně kompatibilní s NTFS ACL, používá je i Sun/Oracle ZFS a další. V Linuxu podopora zatím experimentální.

    - lze se setkat třeba ještě s AFS (Andrew File System), který používá vlastní úplně speciální systém ACL v podstatě s ničím jiným nekompatibilní.

    - zajímavý systém ACL měl Novell NetWare, tzv. Trustee Rights, které považuji za uživatelsky nejpřehlednější implementaci ACL, co jsem zatím viděl. Použitelnost NetWare ACL editoru se s tím, co je součástí Windows absolutně nedá srovnávat.

    Hlavní výhodna NFSv4 ACL je jejich kompatibilita s "Microsoft" ACL, které se používají u NTFS a hlavně CIFS (Sdílení souborů). POSIX ACL nemají všechny vlastnosti (třeba dědění), takže např. Samba musí dělat různá kouzla, aby zobrazení a editace ACL ve Windows editoru alespoň trochu rozumně fungovalo.
    16.5.2010 03:39 EE
    Rozbalit Rozbalit vše Re: ACL standard v Linuxu
    Pekny prehled informaci okolo ACL.

    Snad bych jen vyslovne zduraznil, ze:
    1. ten "standard" POSIX.1e nikdy nebyl prijat, takze technicky vzato to zadny stardard neni. Presto tu jeho cast popisujici ACL hodne OS a FS pouziva.
    2. ani ten NFSv4 "standard" jeste nebyl prijat a odsouhlasen, ale prakticky se na nem obor shodl, takze to bude v nejhorsim pripade moderni obdoba situace s "POSIX.1e"
    POSIX Access Control Lists on Linux (detailni popis)
    12.5.2010 20:48 Sten
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    rsync
    13.5.2010 08:47 dustin | skóre: 61 | blog: dustin
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Souhlasím. Pokud stačí vždy jen aktuální záloha a změn od minulé není zase tolik, musí rsync zvládnout zesynchronizovat 100k souborů do hodiny v pohodě. Obzvlášť pokud se spustí napřímo klient/server, bez režie ssh. Samozřejmě první kopírování bude trvat déle, ale i to by se do hodiny po gigabitu dalo stihnout.

    Pokud by souborů bylo mnoho miliónů, žere rsync spoustu paměti, někdy nám ani nestačil limit paměti 3GB na 32-bitovém systému. Ale 100k souborů nic není, to jsou dva maildirové účty.
    12.5.2010 23:26 Zdeněk Burda | skóre: 61 | blog: Zdendův blog | Praha
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Zkoušel jsi změřit jak dlouho trvá lokálně soubory zabalit tarem? Zkus změřit jak dlouho trvá dump souborového systému. Abys to stihl odzálohovat za hodinu, musel bys zálohovat rychlostí přes 42MiB/s.
    -- Nezdar není hanbou, hanbou je strach z pokusu.
    12.5.2010 23:38 Lithius | skóre: 14
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Tar do roury netcatu a na druhem serveru z netcatu do taru. Otazka je, jak to asi muze byt rychle.
    13.5.2010 08:14 Miklik | skóre: 27 | Krnov
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Jako ostatní doporučuji tar a co nejlepší komprimaci (bzip2,lzma,...) aby se maximálně zmenšil objem přenášených dat. Na druhý server bych to asi přenášel přes nfs nebo ten netcat. Je třeba zkusit kolik co dá po síti. Je třeba asi najít správný poměr pro zatížení CPU kompresí a využití sítě.

    Pokud by se to nedalo stihnou, tak by řešením mohlo být i vytvoření snapshotu. Nevím co přesně omezuje to 1h okno.

    Netvrdím to, ale možná je to pravda.
    13.5.2010 11:36 marek
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Dobry den. Moje zkusenost: Malokdo ma dostatecne silne zelezo, aby si mohl dovolit komprimovat normalni soubory tak rychle, aby na vstupu byl tok alespon 1Gb/s. Takze komprimovat se nevyplati. Ale usifrovat to dost casto je mozne. Takze i nejjednodussi stokrat overeny prikaz:
    tar -cf - /co_chci_kopirovat | ssh uzivatel@server "cat | tar -C kam_chci_kopirovat -xf -"
    
    Ma jako uzke hrdlo rychlost disku. Je jenom otazka, zda to nedelat po celych diskovych obrazech - podle toho jaky ma vykon FS.

    Marek

    AraxoN avatar 13.5.2010 12:48 AraxoN | skóre: 45 | blog: slon_v_porcelane | Košice
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Ten cat tam je nadbytočný... ako aj parameter -f -. Malo by to ísť aj takto:
    tar -c /co_chci_kopirovat | ssh uzivatel@server "tar -x -C kam_chci_kopirovat"
    A fine is a tax for doing wrong. A tax is a fine for doing well.
    13.5.2010 15:47
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Taky by to mohlo jít takhle:
    cd /kam_chci_kopirovat ; ssh uzivatel@server "tar -cf - /co_chci_kopirovat" | tar -x
    14.5.2010 20:08 EE
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    cd /kam_chci_kopirovat
    Jak se jde "cd" do adresare na stroji, na ktery clovek jeste neni ani prihlaseny :)

    Nemelo by to byt:

    ssh uzivatel@server "cd /kam_chci_kopirovat ; tar -cf - /co_chci_kopirovat" | tar -x
    14.5.2010 20:23 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Ne, bylo to správně. Adresář, kam chcete kopírovat, musíte nastavit na tom stroji, na který kopírujete, tj. na tom, kde tar extrahuje.
    14.5.2010 20:44 EE
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Aha, nejak jsem si popletl smery zalohovani a odkud se kam pripojuji. Uznavam, ze ten muj "opraveny" prikaz byl nesmysl, protoze to odkazuje na stejny stroj.

    Z tohohle popisu

    tar -c /co_chci_kopirovat | ssh uzivatel@server "tar -x -C kam_chci_kopirovat"

    jsem si myslel, ze pomoci ssh se pripojuji na stroj, KAM CHCI UKLADAT TU ZALOHU ??

    Misto toho se tedy pomoci ssh pripojuji na stroj, odkud budu zalohovat?
    Aktualizace: Aaaaha, myslim, ze uz to chapu. Ty priklady vyse (prispevek 18 a 19) jsou svoje vzajemne opaky! V jednom pripade je sshd na stroji se zalohou ("18"), v tom druhem na stroji s originaly ("19").

    Zatracene. Stydim se, jak mi to mysli pomalu :(
    14.5.2010 20:55 dustin | skóre: 61 | blog: dustin
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Je úplně jedno, ve kterém směru jde ssh připojení, jenom to pak ovlivňuje, zda se na vzdáleném stroji spustí tar v režimu vytváření archivu (-c) nebo rozbalení (-x).
    14.5.2010 21:14 EE
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Jo, to je jasne. Jenze v tech prikladech vyse se popisuji rozdilne situace: v prispevku 18 je na stroji server (kde bezi sshd) zaloha, kdezto v prispevku 19 jsou tam originaly.

    Snad jsem to nezvoral, protoze jestli ano, tak uz tomu vazne nerozumim. :(

    Jde mi o to, ze na jednom z tech stroju (bud na originalu nebo na zaloze) nemusi bezet sshd, coz muze mit sve vyhody. Pokud na obou bezi sshd, tak tady vazne ztracime cas zbytecnostma.
    14.5.2010 21:35 dustin | skóre: 61 | blog: dustin
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Jasně.

    Nicméně stejně pokud by mi záleželo na celkové době kopírování, jako tazateli, a stroje by byly rozumně přístupné, tak bych to určitě netahal přes ssh, ale rovnou netcatem.
    Heron avatar 14.5.2010 22:04 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Pokud jsou ty lokality daleko od sebe, tak bych naopak doporučoval ssh pro ochranu dat.
    14.5.2010 23:42 EE
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Neni to snem kazdeho admina mit 2 stroje daleko od sebe a presto propojene gigabitem jako autor prispevku? :-)

    Osobne myslim, ze ma oba stroje v jedne mistnosti, ale nedalo mi to, abych si nerypnul.
    15.5.2010 00:49 methuz | skóre: 7 | blog: robutek
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    ;) v jedne mistnosti nejsou (jsou to nody HA clusteru a tam je stejna poloha krajne nezadouci) nicmene vzdalenost je "pouze" ve stovkach metru.
    The only problem with troubleshooting is that sometimes trouble shoots back ..
    13.5.2010 15:49 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    nadbytočný... ako aj parameter -f -

    U aktuálních verzí GNU taru ano. Obecně ne.

    14.5.2010 10:28 marek
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Dobry den. Ten cat je tam skutecne nadbytecny, nicmene prida jeste jeden buffer. Za urcitych okolnosti to melo kdysi lepsi vysledky a ja uz se toho neumim zbavit.

    Marek

    13.5.2010 16:38 methuz | skóre: 7 | blog: robutek
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    mno vyzkousel sem nekolik variant a nejlepe zatim vychazi tar v kombinaci s nfs. zkousel sem vzorek cca 2000 souboru (4,2GB) prohnat tarem ze SANu na lokani disk druheho serveru pres nfs. rychlost byla lehce pres 170MB/s. da se rict ze sem vcelku spokojen. nicmene prave zkousim i dalsi varianty ;)
    The only problem with troubleshooting is that sometimes trouble shoots back ..
    Heron avatar 13.5.2010 08:39 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    100 000 za hodinu to je 36ms na soubor o průměrné velikosti 1.5MB. Pro celek HW, OS, FS s latenci i kdyby jen 10ms to znamená přenést 1.5MB za 26ms tj 62MB/s. Tohle 7200 rpm (nenapsal jste HW, pokud tam máte 15krpm v raid10, tak se nemáme o čem bavit) disk, zvládne jen za předpokladu, že to tam poběží jako jediná úloha a ty soubory nebudou fragmentované. Ten úkol je hodně zapeklitý. :-)

    Pokud se ta data se nemění celá (celých 150 GB) a jen přirůstají, tak bych preferoval rsync. Na počátku to poběží hodně dlouho, ale pak už to bude jen zlomek té požadované hodiny. Tímto bych začal.

    Pokud se ta data mění výrazně, tak bych se úplně vykašlal na soubory a přenášel bych přímo obraz těch FS. Což znamená ho na ten okamžik zálohy odpojit, nebo alespoň přepnout do režimu jen pro čtení. To pak poběží rychlostí toho gigabitu, kontinuální čtení nad 100MB/s dnes zvládne kde co.
    13.5.2010 08:58 dustin | skóre: 61 | blog: dustin
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Kopírování celého obrazu je samozřejmě nejrychlejší (za předpokladu, že je aspoň trochu zaplněn, takže nárůst přenášených dat není tak velký). Ale mám zkušenost, že se obě strany nesmí ničím jiným vyrušovat, pak jde samozřejmě rychlost do kytek. Ale to platí pro běžná disková pole mdadm, HW SANy neznám. Je také otázkou, zda je zamčení fs pro zápis po tu dobu akceptovatelné.

    Na našem zálohovacím serveru kopírujeme raid1 mirrorováním, je to velice flexibilní, při zátěži rychlost synchronizace spadne, v klidu se zase rozjede, co dají disky. Po sesynchronizování se záloha udržuje aktuální, dokud ručně skriptem backup stranu neodpojíme (včetně umount/mount fs na primární straně, aby byl konzistentní). Ale tam jsou desítky miliónů souborů a rsync nepřichází v úvahu.

    Zde mi ten rsync vychází stále nejlépe.
    14.5.2010 20:58 EE
    Rozbalit Rozbalit vše 150GB obraz
    Pokud se ta data mění výrazně, tak bych se úplně vykašlal na soubory a přenášel bych přímo obraz těch FS
    Me by zajimalo, co byste doporucil delat s tim 150GB obrazem na druhe strane, tedy na tom stroji se zalohou. Ulozit to jako soubor? Flaknout to na vyhrazene misto na disku jako dalsi oddil (partition)? Ulozit to za vsechny dalsi oddily na disku jako dalsi extended partition?
    14.5.2010 21:03 dustin | skóre: 61 | blog: dustin
    Rozbalit Rozbalit vše Re: 150GB obraz
    Samozřejmě nejrychlejší je to uložit do nějaké další partišny, která by pak šla normálně namontovat. Ukládání do souboru na filesystému je pomalejší o režii FS, namontovat pak lze taky snadno přes loopback.

    Tazatel bohužel za celou dobu neřekl, jak jsou vlastně ty oddíly velké, ale lze předpokládat asi výrazně více, než těch 150GB zaplněného prostoru.
    14.5.2010 21:25 EE
    Rozbalit Rozbalit vše Re: 150GB obraz
    Ukládání do souboru na filesystému je pomalejší o režii FS
    Jasne. Navic pokud clovek nema ta existujici data na oddilu, kam zapisuje tu zalohu, "sklepana", tak jeste hlava disku leta sem a tam jak zaplnuje diry ve FS. V kazdem pripade vykon jde brutalne dolu.

    Taky bych daval prednost zapisu cele partition, kdyby ta data byla na jedne 150GB, coz zrejme nebude pripad tazatele, jak spravne uvadite.
    Heron avatar 14.5.2010 21:43 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: 150GB obraz
    Já bych ho dal do LV. Soubor na disku má jisté nevýhody jak správně píše dustin.
    15.5.2010 00:34 EE
    Rozbalit Rozbalit vše Re: 150GB obraz
    Myslite udelat z nej dalsi virtualni partition na Logical Volumes?

    Hmmm, to ma neco do sebe. Odpadaji starosti s problemy udrzet si poradek ve fyzickych oddilech na disku/discich.

    Navic kdyz je to posazene nad mdadm, tak je to i chranene proti problemum s disky.
    Heron avatar 15.5.2010 08:01 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: 150GB obraz
    Ano, takto jsem to přesně myslel.
    13.5.2010 09:24 l4m4
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Jak píší ostatní, pokud jde o udržování kopie, je nejlepší řešení rsync, především může-li věřit mtime, a v tom případě by to měl zvládnout i podstatně rychleji. Jinak ovšem musí těch 150 GB stejně přečíst (na obou stranách), tudíž platí pro něj platí stejné výpočty + komplikace dané složitejším algoritmem.

    Ideální scénář, je-li možný, je vytvořit prvotní kopii pomalu, bez zátěže primárního serveru -- třeba za den. To se provede pouze jednou na začátku a tato kopie nemusí být konzistetní snapshot, stačí, aby byla dostatečně podobná a ušetřilo se při následném rsyncování. Pro vlastní zálohování se pak použije rsync.
    13.5.2010 09:37 methuz | skóre: 7 | blog: robutek
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    To jsem ponekud zapomnel zminit. Potrebuji ty souboru pretahnout pouze jednou - denni zalohovani a vubec zalohovani je reseno uplne jinak ale bohuzel pomalu na to abych ho mohl vyzit i tady. rsync mi prijde na tenhle one-time job zbytecny. momentalne spis premyslim mezi tarem a dumpem filesystemu.
    The only problem with troubleshooting is that sometimes trouble shoots back ..
    13.5.2010 10:37 dustin | skóre: 61 | blog: dustin
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    To je dost podstatná informace :) Stejně jako velikost těch fs (tj. míra jejich zaplnění - viz příkaz df), zda je lze po tu hodinu odmontovat, zda po tu dobu bude k diskovému zařízení přistupovat i něco jiného atd. Pak se lze rozhodnout, zda dd + netcat nebo tar + netcat.
    Marek Stopka avatar 13.5.2010 11:12 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Vzít vlákno, propojit ty 2 SAN Fabric a udělat sync na úrovni těch polí? :)
    13.5.2010 12:18 methuz | skóre: 7 | blog: robutek
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    ano, normalni clovek v idealnim svete by to udelal takto. ale nezijeme v idealnim svete (a zmineny SANy jsou na druhym konci naseho neidealniho sveta nez ja ;) )
    The only problem with troubleshooting is that sometimes trouble shoots back ..
    Marek Stopka avatar 13.5.2010 15:53 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    Tak pořád tam bude nějaký on-site, facility management, nebo někdo kdo umí zapojit kabel z jednoho portu SAN switche do jinýho, ne?
    13.5.2010 16:33 methuz | skóre: 7 | blog: robutek
    Rozbalit Rozbalit vše Re: Prenos velkeho mnozstvi souboru
    ne. je tam jen clovek co je schopen restartovat server. tlacitkem. (nastesti mame RSA karty...)
    The only problem with troubleshooting is that sometimes trouble shoots back ..
    15.5.2010 03:17 EE
    Rozbalit Rozbalit vše RSA karty
    RSA? Remote Secure Access? Neco jako tohle od Intelu nebo tohle od Dellu?
    15.5.2010 06:02 Ash | skóre: 53
    Rozbalit Rozbalit vše Re: RSA karty
    IMHO se tomu říká spíš Remote Supervisor Adapter, odkaz máte z té druhé vámi odkazované stránky IBM RSA.
    15.5.2010 18:43 methuz | skóre: 7 | blog: robutek
    Rozbalit Rozbalit vše Re: RSA karty
    ano, mel jsem namysli Remote Supervisor Adapter. Vcelku slusny popis je i na wiki. (http://en.wikipedia.org/wiki/IBM_Remote_Supervisor_Adapter) Snad jen doplnim ze do novejsich IBM masinek uz se dava nastupce RSAcka - IMM. Integrated Management Module (http://www.scribd.com/doc/13780646/IMM-Users-Guide - wiki jsem nenasel)
    The only problem with troubleshooting is that sometimes trouble shoots back ..

    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.