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í
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
dnes 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 0
dnes 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
včera 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 15
včera 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 8
včera 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 2
včera 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
včera 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

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

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
1.12. 21:00 | Nová verze

Byla vydána beta verze Linux Mintu 18.1 s kódovým jménem Serena. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu s prostředím MATE a druhé o vydání Linux Mintu s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18.1 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
1.12. 16:42 | Nová verze

Byl vydán Devuan Jessie 1.0 Beta 2. Jedná se o druhou beta verzi forku Debianu bez systemd představeného v listopadu 2014 (zprávička). První beta verze byla vydána v dubnu letošního roku (zprávička). Jedna z posledních přednášek věnovaných Devuanu proběhla v listopadu na konferenci FSCONS 2016 (YouTube, pdf).

Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 767 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Prenos velkeho mnozstvi souboru

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

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: 50 | 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: 60 | 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: 60 | 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: 60 | 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: 50 | 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: 50 | 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: 60 | 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: 60 | 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: 50 | 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: 50 | 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: 60 | 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.