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 <[email protected]> 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 >> [email protected] >> http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro >> > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
