--inplace poate fi o binefacere sau un blestem, in functie de imprejurari, de obicei prefer sa nu-l folosesc decat cand chiar e musai nevoie de el (better safe than sorry)
revenind la oile noastre strict cu -H, tot nu am gasit vreo referinta ca s-ar comporta diferit daca chiar sunt hardlink-uri in sursa fata de cazul in care nu ar fi iar pentru cazul (testat) in care nu sunt, nu am vazut schimbari evidente in utilizarea de memorie pe parcursul transferului (cu si fara -H); deci nu prea inteleg momentan de ce se plange lumea de extra consum de memorie si posibil blocari de sistem atunci cand volumul de date si numarul de fisiere este semnificativ ... Alex On 09-Oct-19 4:01 PM, Cristian Paslaru wrote: > Daca doar vrei sa mentii o copie cat mai unu la unu si cu cat mai putin > transfer si unde -H ar merge cum ar trebui poti folosi optiunea de > --inplace > > On Wed, Oct 9, 2019 at 3:02 PM Alex 'CAVE' Cernat <c...@cernat.ro> wrote: > >> On 09-Oct-19 2:45 PM, Cristian Paslaru wrote: >>> Salut, >>> >>> la 1. este in vfs: >>> >> https://www.usenix.org/legacy/publications/library/proceedings/usenix01/full_papers/kroeger/kroeger_html/node8.html >> deci de fapt e si mai bine, intra pe page cache (aka bucati de fisier), >> deci ar trebui sa ramana o singura copie in memorie oricate >> hard-link-uri ar fi existente (pentru ca refera aceeasi portiune de date >> de pe disk) >>> 2. la rsync cu multe hard-links incepe slow down si limita de inodes in >> FS, >>> nu neparat de storage still available, aveam some backups servers cu >> rsync >>> cu hard-links, si ca sa "overcome the issue of scanning all older >> folders" >>> foloseam --list-dest doar cu last previous days of backups, si merge fara >>> issues. Daca dadeam pentru all old folders, atunci la peste 7 zile de >>> backups incepea slowdown-ul. >>> Use-case-ul tau e pentru backups, sau altceva? >>> >>> Sporuri. >> m-ar interesa strict ca hard-link-urile de pe sursa sa se materializeze >> in hard-link-uri pe destinatie (ma rog, sunt acolo niste posibile >> "feature-uri" in care desi un fisier e hard-link-at e posibil sa fie >> transferat si dupa aia nu stiu, cred ca e sters la destinatie si facut >> hard-link asa cum trebuie, in functie de cum vine ordonata lista de >> fisiere in rsync; nu e perfect, dar e acceptabil) >> >> si nu, nu ma intereseaza sa pastrez "snapshot-uri" facute de rsync ca >> hard-linkuri (am testat / cred ca si folosit mai de mult, dar e criminal >> pe masura ce trece timpul), pentru asta un snapshot la nivel de >> filesystem (cu conditia sa si suporte asa ceva) e o solutie cu ani >> lumina mai departe >> >> Alex >> >>> On Wed, Oct 9, 2019 at 2:31 PM Alex 'CAVE' Cernat <c...@cernat.ro> >> wrote: >>>> Salut >>>> >>>> Doua intrebari destul de low level legat de hard-link-uri: >>>> >>>> 1. cum tine linux-ul cache-ul cand e vorba de hard-linkuri ? sper ca >>>> tine la nivel de i-node, recte daca exista x fisiere accesate care >>>> pointeaza catre aceeasi zona de date (acelasi inode) se pastreaza o >>>> singura copie in cache, nu x bucati (nu stiu daca e de vfs sau >>>> implementare de filesystem, in cazul al doilea ar fi curios de stiut la >>>> ext4, xfs, zfs si nfs) >>>> >>>> 2. se plange lumea pe net ca optiunea -H (preserve hard links) genereaza >>>> posibile blocari si memory bomb-uri atunci cand e folosita pe directoare >>>> cu multe fisiere; din ce am facut niste teste nu am vazut modificari >>>> majore in memoria programului nici la sender, nici la receiver, in >>>> conditiile in care nu exista momentan din cate stiu hard link-uri in >>>> datele respective (testat inclusiv cu vreun milion de fisiere, ceea ce >>>> incepe sa devina semnificativ, dar dupa cum ziceam fara hard link-uri); >>>> dupa cum as implementa eu algoritmul, as trimite in plus in lista de >>>> fisiere/metadate si inode-ul (sau combinatie de fsid/partitionid/blockid >>>> si inode) iar in receiver as tine seama de informatiile astea daca e >>>> prezenta optiunea; s-ar putea totusi sa nu fie implementat asa, iar >>>> diferenta sa se simta doar daca exista efectiv hard-link-uri (eventual >>>> multe) in datele transferate; intrebarea e: si-a bagat cineva >>>> surubelnita destul de adanc in codul de rsync incat sa ma lamureasca si >>>> pe mine ce si cum ? >>>> >>>> mersi >>>> >>>> Alex >>>> >>>> >>>> _______________________________________________ >>>> RLUG mailing list >>>> RLUG@lists.lug.ro >>>> http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro >>>> >>> _______________________________________________ >>> RLUG mailing list >>> RLUG@lists.lug.ro >>> http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro >> >> >> _______________________________________________ >> RLUG mailing list >> RLUG@lists.lug.ro >> http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro >> > _______________________________________________ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
