salut si la multi ani laudam eu mai de mult xfs-ul, dar la niste teste in productie m-a facut sa-l cam injur la greu
concret, test de rsync incremental sau snapshot-ial, cum se zice (rsync && cp -al) prin decembrie, pe o troaca de masina (macar era aceeasi masina de test), xfs-ul a iesit destul de ok, ce-i drept cu o penalitate de 20-30% ca timp mai mult fata de ext4, dar cu overheadul de metadate de hardlinkuri cam la un sfert (maxim o treime) din ext4/4k, ceea ce parea foarte promitator; performantele erau destul de apropiate cu un ext4/2k, in continuare cu un castig la overhead de metadate pe scula propriu-zisa: stupoare, xfs-ul merge cam de 2-3 ori mai lent decat ext4 (din ce am vazut diferente intre 2k si 4k nu sunt notabile, iar 1k refuza din start sa mi-l formateze, oricum functionase groaznic la testele precedente, acum era doar din curiozitate) de fapt mai concret: - rsync initial (deci copiere full date) - xfs de vreo 2-3 ori mai lent - rsync doar verificare - parca usor mai rapid - cp -al - xfs clar mai rapid - si la stergere parca xfs-ul a fost mai rapid (nu cu mult), desi in teorie lucrurile ar fi trebuit sa stea exact invers testele facute binenteles cu drop cache inainte de orice operatie, ca sa nu compar mere cu pere pana aici ar fi fost relativ ok, pentru ca in principiu datele nu se modifica foarte des, in marea majoritate diferentele sunt destul de mici, astfel incat overall xfs-ul ar castiga detasat problema este ca by default partitia de xfs e montata cu inode32, ceea ce inseamna ca toate inodurile vor fi stocate in primul terabyte din hard, cu posibilitatea (teoretica) de a ramane fara spatiu de creat fisiere, desi spatiu pe disc exista garla !!! ce nu am inteles exact din documentatie este daca xfs-ul este destul de inteligent incat cu inode32 sa lase liber pe cat posibil spatiul din primul tera, si sa-l foloseasca restul ramas teoretic pot linistit sa adaug inode64 la montare oricand am chef, nu am inteles exact daca odata ce am montat cu inode64 mai pot sa revin la 32, initial nu se putea, dar prin niste articole se specifica ca de la 2.6.toamna avem si aceasta posibilitate folosind inode64 problema s-a schimbat, in sensul ca: - timpul de rsync initial s-a redus, dar tot ramane la vreo de 2 ori mai mare ca la ext4 - rsync-ul de verificare (local = remote) a inceput sa creasca - cp -al a crescut si el si a depasit timpul la ext4 - a crescut si overheadul de metadate pentru cp -al (ceea ce oricum era de asteptat) overall, parca folosirea lui inode64 face mai mult rau decat bine ... mai testez diverse combinatii sa vedem ce si cum iese la sfarsit am testat cu diverse stripe-uri de md / raid 5 (momentan nu vad nicio diferenta notabila, decat cel mult la un dd sustinut, dar nu asta ma intereseaza), am avut grija ca xfs-ul sa stie de parametri de raid (de fapt a stiut el singur, eu doar am incercat sa-l verific), noatime nu a bagat nicio diferenta notabila, modificari in logurile xfs-ului nu prea am avut ce face (ba chiar recomandarile de pe net de 'maxim' erau mai mici decat cele puse automat la formatare), singura optiune care a avut efect a fost nobarrier, dar a fost strict de test sa vedem daca chiar se vede ceva; si s-a vazut, oarecum, dar nu destul ... are de la mama lui delaylog bagat la mount, alte modificari chiar nu-mi trec prin cap (oricum, era si o gluma, ca cel mai bun tuning pentru xfs e sa lasi setarile default, pe care si le determina singur) ca sistem, un debian wheezy, raid 5 pe 5 harduri ce alte energizante pot sa-i mai dau ? ca am incercat cu de toate si tot le cam doarme ... danke Alex _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
