On Thu, Feb 18, 2010 at 12:45:52PM +0100, Kaminar wrote:
> > A pouzit uz pri vytvarani zalohy rsync --backup-dir by nebolo mozne?
>
> Byla to uplne prvni zaloha toho disku, takze nebyl duvod pouzit rsync.
>
> > Najdenie rozdielov sa zredukuje na prikaz find xy/ -links 1
>
> Jenze to mi jen zkont
On 02/18/10 13:03, Dan Lukes:
Pokud jsi kopiroval skutecne sektory, tak tam k odlisnostem
prakticky dojit nemuze.
Pospicham a placam tak, ze to nemuz ebyt pochopitelne. Nahrad v
predchozi vete slovo "sektor" slovem "soubor". Pak to zacne davat smysl.
On 02/18/10 12:45, Kaminar:
I kdyz zatím to predbezne vypada, ze kdyz uz k chybe doslo, tak se soubory
nezkopirovaly.
No,z alezi jak jsi to kopiroval. Ja myslel, ze mas image disku (sektor
by sektor). Pokud jsi kopiroval skutecne sektory, tak tam k odlisnostem
prakticky dojit nemuze.
Proto
^-- Ak som spravne pochopil, porovnavas rychlost _zapisu_, pricom
subory su zapisovane po jednom sekvencne a spracovanie je krasne
streamove a mozu sa plne vyuzit vsetky cache pamate po ceste, s takmer
paralelnym _citanim_ dvoch suborov na porovnanie, kedy sa na tie data
proste musi cakat? Do
> A pouzit uz pri vytvarani zalohy rsync --backup-dir by nebolo mozne?
Byla to uplne prvni zaloha toho disku, takze nebyl duvod pouzit rsync.
> Najdenie rozdielov sa zredukuje na prikaz find xy/ -links 1
Jenze to mi jen zkontroluje chybejici soubory, ale ne jestli
se jedna o binarne shodne soubo
On 02/18/10 11:53, Kaminar:
Jestli je treba pri simultannim cteni tech dvou souboru neustale
seekovat tak to zhruba odpovida.
To me dost prekvapilo, jak velky je v tom rozdil.
Posun hlavicky - to je mechanicka akce a pro tu plati limity fyzikalnich
zakonu. To je casove strasne draha vec.
A pouzit uz pri vytvarani zalohy rsync --backup-dir by nebolo mozne?
Najdenie rozdielov sa zredukuje na prikaz find xy/ -links 1
Na zalohovanie vid. dirvish, nadstavba nad rsync.
rajo
On Thu, Feb 18, 2010 at 11:53:53AM +0100, Kaminar wrote:
>> Jestli je treba pri simultannim cteni tech dvou soub
Jestli je treba pri simultannim cteni tech dvou souboru neustale
seekovat tak to zhruba odpovida. ZKusil jsme to na svem velmi nevykonnem
domacim routeru. Cteni 800MB z disku sekvencne:
To znamena, ze v druhem pripade trva precteni 400MB trinackrat dele nez
v pripade prvnim a namerena rychlost
On Wed, Feb 17, 2010 at 09:51:04PM +0100, Jan Pechanec wrote:
> On Wed, 17 Feb 2010, Dan Lukes wrote:
>
> > On 02/17/10 21:01, Jan Pechanec:
> >>pravdepodobnost, ze nahodne vybrane 2 soubory budou mit stejny MD5
> >> hash, je 1/2^128
> >
> > Nase soubory ale nejsou tak uplne nahodne vybrane a
On Wed, 17 Feb 2010, Dan Lukes wrote:
> On 02/17/10 21:01, Jan Pechanec:
>> pravdepodobnost, ze nahodne vybrane 2 soubory budou mit stejny MD5
>> hash, je 1/2^128
>
> Nase soubory ale nejsou tak uplne nahodne vybrane a o jejich obsahu take
> nevime
> nic - mozna neni vzajemne nahodny.
>
>> m
On 02/17/10 21:01, Jan Pechanec:
pravdepodobnost, ze nahodne vybrane 2 soubory budou mit stejny MD5
hash, je 1/2^128
Nase soubory ale nejsou tak uplne nahodne vybrane a o jejich obsahu take
nevime nic - mozna neni vzajemne nahodny.
myslim, ze je to v uvazovanym pripade naprosto zbyt
On Wed, 17 Feb 2010, Jozef Babjak wrote:
>Btw, nepouziva bsd balickovaci system na kontrolu integrity archivov
>zdrojakov od urciteho casu nielen MD5, ale kombinaciu MD5+SHA
>kontrolnych suctov? Nac pak to, ked "spolahlivo" staci MD5?
to ti vysvetlim - to je totiz uplne jina situace, tam
On Wed, 17 Feb 2010, Dan Lukes wrote:
> A jestli ne ?
>
> Zalezi jestli budou soubory casteji shodne nebo casteji ruzne. Pokud se da
> ocekavat, ze budou vetsinou ruzne, pak si muzeme dovolit v pripade shodneho
> hashe soubory skutecne 1:1 porovnat. Nebudeme to delat casto.
>
> Pokud se naopak da
On 02/17/10 20:22, Jan Pechanec:
MD5 ma 128 bitu, tj. tolik ruznych moznosti vystupu:
340282366920938463463374607431768211456
Tvoje argumentace je dvojsecna.
md5 ma 128 bitu a tudiz hash skutecne muze nabyvat cca 3.4^38 ruznych
moznych hodnot, na druhou stranu - je zrejme, ze toto mn
> no, me to co rikas prijde v nasi situaci takovy nesmysl, ze ani
> nevim, jak rozumne odpovedet. Pravdepodobnost, ze dva _rozdilny_ soubory
^-- Ale no tak, ja som si to nevymyslel. Linuxove jadro obsahuje
mechanizmus deduplikacie stranok, ktory fungue presne tak, ako som
opisal: porovnav
On Wed, 17 Feb 2010, Dan Lukes wrote:
>> ^-- Co mu sice spolahlivo identifikuje rozdielne subory, ale rovnake
>> musi stale prehnat tym diffom, aby sa presvedcil, ze su skutocne
>> rovnake.
>
> No, ja myslim, ze dokonce i na te dnes jiz prekonane md5 je pravdepodobnost
> kolize natolik mala, ze
On Wed, 17 Feb 2010, Jozef Babjak wrote:
>> nebo, coz muze byt levnejsi, to prohnat postupne tou md5 :-)
>
> ^-- Co mu sice spolahlivo identifikuje rozdielne subory, ale rovnake
>musi stale prehnat tym diffom, aby sa presvedcil, ze su skutocne
>rovnake.
no, me to co rikas prijde v
On 02/17/10 19:58, Jozef Babjak:
nebo, coz muze byt levnejsi, to prohnat postupne tou md5 :-)
Casove se tato metoda skutecne vyplati:
dd if=/dev/ad4 of=/dev/stdout bs=1m count=400 | md5
419430400 bytes transferred in 18.584731 secs (22568548 bytes/sec)
Takze spocitat u dvou soboru a p
> nebo, coz muze byt levnejsi, to prohnat postupne tou md5 :-)
^-- Co mu sice spolahlivo identifikuje rozdielne subory, ale rovnake
musi stale prehnat tym diffom, aby sa presvedcil, ze su skutocne
rovnake.
J.
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/li
On Wed, 17 Feb 2010, Dan Lukes wrote:
> Zkratka a dobre receno - ty nepotrebujes lepsi program na porovnani. Ty na
> zadanou ulohu potrebujes vhodnejsi hardware.
nebo, coz muze byt levnejsi, to prohnat postupne tou md5 :-)
--
Jan Pechanec
http://www.devnull.cz
--
FreeBSD mailing list
On 02/17/10 19:14, Kaminar:
nerikej, ze kdybys to pustil tim diffem, ze nebudes mit vysledek
driv, nez dostanes z konference rozumnou odpoved ;-)
Nebylo. :) Asi 10GB trvalo diffem cca 1:20h.
20GB/80min to je asi 4MB/s
Jestli je treba pri simultannim cteni tech dvou souboru neustale
> "--brief" je to same jako "-q"?
^-- Ze by to nebolo napisane ani v manuali ani tu:
http://www.freebsd.org/cgi/man.cgi
> A nemohl by ten casovy rozdil byt ve vykonu PC? Mam 2,4GHz Celeron
> a bezi na nem FBSD 6.0.
^-- S pravdepodobnostou hraniciacou s istotou nie. Skor memory
bandwidth. Al
>> To, co te zdrzuje neni diff, ale rychlost disku, ze ktereho ctes.
>
> To ale asi nezdrzuje.
>
> Kdyz jsem kopiroval tech 60GB z HDD (sifrovany) na externi HDD,
> tak to trvalo cca 2h a to jsem to kopiroval ze zasifrovaneho disku.
>
> Kdyz jsem porovnaval 10GB (cast tech kopirovanych dat) na nesi
> ^-- Ok, budeme radi, ak nas zoznamis s rychlejsou metodou. A to
> vobec nemyslim ironicky - sam pouzivam zmienenu kombinaciu
>
> diff -r --brief
"--brief" je to same jako "-q"?
A nemohl by ten casovy rozdil byt ve vykonu PC? Mam 2,4GHz Celeron
a bezi na nem FBSD 6.0.
Karel
--
FreeBSD maili
Well,
viem si predstavit, ze nejaka implementacia moze fungovat menej
efektivne, napr. ak je zalozena na citani riadkov a pod., co sa zda
ako prirodzeny pristup, ak predpokladame textovy vstup.
Akokolvek, ak su sobory rovnake, tak na tom az tak nezalezi, lebo sa
oba porovnavane subory musia v kon
> Nebylo. :) Asi 10GB trvalo diffem cca 1:20h.
^-- To je ale iba latencia, ktoru si k procesu _pridal_, nie?
J.
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
> je moc pomaly. Neni pod FreeBSD nejaky nastroj, ktery by to zvladl
> rychleji, nez diff?
Pokud k tomu '-r' pridas jeste '-q' tak ne. Protoze v takovem pripade se
Pouzival jsem i "-q".
nejprve porpvna delka (nesouhlasi-li pak soubory nejsou stejne) a pokud
je delka stejna, tak se oba soubor
>> ^-- Akoze "diff -r --brief this that" zabere cosi viac ako citanie
>> tych suborov?
>
> V mem pripade zabyra docela hodne.
^-- Ok, budeme radi, ak nas zoznamis s rychlejsou metodou. A to
vobec nemyslim ironicky - sam pouzivam zmienenu kombinaciu
diff -r --brief
niekolkokrat denne na porov
On 02/17/10 19:16, Jozef Babjak:
To, co te zdrzuje neni diff, ale rychlost disku, ze ktereho ctes.
^-- Dalo by sa na to odpovedat na meta-urovni: tazko najs na
porovnanie suborov nieco lepsie, ako nastroj na ... surprise...
porovnavanie suborov.
No, to zase trochu pozor. diff neni od pocat
> > prohnal pres md5 a diffnul vystupy. md5 je tak rychla, ze nejvic zabere
> > cteni tech souboru.
>
> ^-- Akoze "diff -r --brief this that" zabere cosi viac ako citanie
> tych suborov?
V mem pripade zabyra docela hodne.
Karel
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.c
> To, co te zdrzuje neni diff, ale rychlost disku, ze ktereho ctes.
^-- Dalo by sa na to odpovedat na meta-urovni: tazko najs na
porovnanie suborov nieco lepsie, ako nastroj na ... surprise...
porovnavanie suborov.
J.
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/
> nerikej, ze kdybys to pustil tim diffem, ze nebudes mit vysledek
> driv, nez dostanes z konference rozumnou odpoved ;-)
Nebylo. :) Asi 10GB trvalo diffem cca 1:20h.
Karel
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
On 02/17/10 17:42, Kaminar:
potreboval bych binarne porovnat velky pocet souboru rekurzivnim
prochazenim adresaru, celkem cca 60GB dat. Zkousel jsem diff -r, ale
je moc pomaly. Neni pod FreeBSD nejaky nastroj, ktery by to zvladl
rychleji, nez diff?
Pokud k tomu '-r' pridas jeste '-q' tak ne. Pr
> prohnal pres md5 a diffnul vystupy. md5 je tak rychla, ze nejvic zabere
> cteni tech souboru.
^-- Akoze "diff -r --brief this that" zabere cosi viac ako citanie
tych suborov?
J.
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
On 17 Feb 2010, at 18:46, Jan Pechanec wrote:
> On Wed, 17 Feb 2010, Kaminar wrote:
>
>> Zdravim,
>>
>> potreboval bych binarne porovnat velky pocet souboru rekurzivnim
>> prochazenim adresaru, celkem cca 60GB dat. Zkousel jsem diff -r, ale
>> je moc pomaly. Neni pod FreeBSD nejaky nastroj, kte
On Wed, 17 Feb 2010, Kaminar wrote:
>Zdravim,
>
>potreboval bych binarne porovnat velky pocet souboru rekurzivnim
>prochazenim adresaru, celkem cca 60GB dat. Zkousel jsem diff -r, ale
>je moc pomaly. Neni pod FreeBSD nejaky nastroj, ktery by to zvladl
>rychleji, nez diff?
nerikej, ze kdyb
Zdravim,
potreboval bych binarne porovnat velky pocet souboru rekurzivnim
prochazenim adresaru, celkem cca 60GB dat. Zkousel jsem diff -r, ale
je moc pomaly. Neni pod FreeBSD nejaky nastroj, ktery by to zvladl
rychleji, nez diff?
Karel
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.free
37 matches
Mail list logo
