2016-07-27 12:06 GMT+02:00 lista email <[email protected]>: > Chiar tie ti-am raspuns acum 2 mesaje si am dat outputul unui mount|grep > ^/ in care se vad toate atributele: > > (rw,relatime,attr2,inode64,logbsize=256k,sunit=512,swidth=512,noquota) > > nu am de ce sa schimb, am si precizat inca din primul post ca optiunea de > la xfs_grow -m nu ma intereseaza. Cele doua / sunt formatate la fel. > > Pe 25 Iulie avem (max number of inodes = 67k): > ]# df -i > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/mapper/centos-root 66960 66165 795 99% / > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > apoi fara sa modific nimic, am dat un grow asa de "reglaj" sa vad ce se > intampla ... si stupiza ... face grow ... > # xfs_growfs /dev/mapper/centos-root > > stupiza devine si mai mare, a facut "ceva" grow, dar doar la inoduri > (dimensiunea a ramas neschimbata, 50GB) > # df -i > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/mapper/centos-root 83200 66165 17035 80% / > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Ieri, am vazut va numarul maxim de inoduri a inceput sa scada in timp ce > numarul de inodes used ramanea aproximativ la fel... din nou stupiza > > astazi, 27 Iulie, numarul maxim de inoduri a ajuns din nou la fel ca pe 25 > iulie, iar numarul de inodes used este aproape la fel ca acum 2 zile. > # df -i > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/mapper/centos-root 67024 66225 799 99% / > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Si asta se intampla doar pe acel server. Nu stiu cum a ajuns sistemul in > halul acesta, asa l-am preluat ... dar nu e normal ca numarul maxim de > inoduri sa scada asa din senin. Am trimis un email la dezvoltatorii xfs ... > sigur nu e in regula ce se intampla acolo. >
probabil superblock-ul e corupt, si dupa orice operatie care are ca rezultat modificarea/scrierea superblock-ului output-ul se schimba (asta daca nu o fi vreun bug in xfs). Prin loguri nu ai nimic relevant ? Inainte de as astepta raspuns de la cei de la xfs , probabil ar fi mai bine sa bootezi in rescue mode , sa faci un xfs_check si eventual xfs_repair si sa vezi care e rezultatul ! Un output la lsblk -i ar fi fost mai elocvent ca sa ne lamurim care e configuratia (partiti/PV, LV si filesystem). P.S xfs is for speed not reliability :) > > Ca si fix, ar fi: > - sa mut toate datele din acel / pe alt slice/disk sa reformatez din nou / > si apoi sa aduc datele inapoi sau > - sa incerc xfs_check/repair > si toate operatiile trebuiesc facute offline. > > O sa mai vad ... sunt curios ce sugereaza cei de la xfs. > -------------------------------------------- > On Wed, 7/27/16, Cristian Paslaru <[email protected]> wrote: > > Subject: Re: [rlug] partition 100% full No space left on device > To: "lista email" <[email protected]> > Cc: "Romanian Linux Users Group" <[email protected]> > Date: Wednesday, July 27, 2016, 12:12 PM > > Ai inode64 > mount option setat la ambele? > De asemenea poti schimba imaxpct=25 > to imaxpct=5 de exemplu, folosind xfs_growfs:-m > imaxpct set inode max percent to imaxpct > > > 2016-07-26 17:06 GMT+03:00 > lista email <[email protected]>: > Hmmm ... > cred ca aici este buba: > > > > "Pe nodul cu problema (numar max de inoduri raportat de > df: > > 70k): in scadere fata de acum o ora cu vreo 10k :)) dar > > ordinul de marime ramane." > > > > Ieri am dat un xfs_grow pe / (fara sa modific ceva > prin system) si dupa ce a terminat, am vazut ca mi-a marit > putin numarul de inoduri, de la 66k undeva la 85K, de aceea > astazi de dimineata gradul de utilizare a inodurilor era > undeva in jur de 80%. Acum vad ca se apropie din nou de > cifra de ieri (inainte de a da xfs_grow). > > > > Ba mai mult, dimensiunea ei ramane constanta si numarul de > inoduri folosite ramane si el aproximativ constant ~66k! > > > > In mod normal numarul maxim de inoduri este fix (rezulta > dupa formatare) si cel care creste sau scade este numarul de > inodes USED. Nu e in regula ... in acest context, ma intreb > cum este posibil ca numarul maxim de inoduri pentru partitia > radacina (/) SA SCADA, sau sa fie variabil???!!! Asta suna a > voodoo! > > > > -------------------------------------------- > > On Tue, 7/26/16, lista email > <[email protected]> > wrote: > > > > Subject: Re: [rlug] partition 100% full No space left on > device > > To: "lista email" <[email protected]>, > "Romanian Linux Users Group" <[email protected]>, > "Cristian Paslaru" <[email protected]> > > Date: Tuesday, July 26, 2016, 4:02 PM > > > > Nu e de la isize. Are valoarea > > default (isize=256). M-am uitat cu xfs_info de la > inceput. > > Am si mentionat ca outputul de la xfs_info este similar > > pentru ambele servere, DAR numarul maxim de inoduri > difera > > foarte mult. > > > > Pe nodul cu problema (numar max de inoduri raportat de > df: > > 70k): in scadere fata de acum o ora cu vreo 10k :)) dar > > ordinul de marime ramane. > > > > # df -i|grep root > > /dev/mapper/centos-root 69120 > > 66223 2897 96% / > > > > # xfs_info / > > meta-data=/dev/mapper/centos-root isize=256 > > agcount=17, agsize=819136 blks > > = > > > > sectsz=512 attr=2, > > projid32bit=1 > > = > > > > crc=0 finobt=0 > > data = > > > > bsize=4096 blocks=13107200, > > imaxpct=25 > > = > > > > sunit=64 swidth=64 > > blks > > naming =version 2 > > > > bsize=4096 ascii-ci=0 ftype=0 > > log =internal > > > > bsize=4096 blocks=6400, > > version=2 > > = > > > > sectsz=512 sunit=64 blks, > > lazy-count=1 > > realtime =none > > > > extsz=4096 blocks=0, > > rtextents=0 > > > > Pe nodul sanatos (numar max de inoduri raportat de df: > > 52milioane): > > > > # df -i|grep root > > /dev/mapper/centos-root 52424704 66137 > > 52358567 1% / > > > > # xfs_info / > > meta-data=/dev/mapper/centos-root isize=256 > > agcount=16, agsize=819136 blks > > = > > > > sectsz=512 attr=2, > > projid32bit=1 > > = > > > > crc=0 finobt=0 > > data = > > > > bsize=4096 blocks=13106176, > > imaxpct=25 > > = > > > > sunit=64 swidth=64 > > blks > > naming =version 2 > > > > bsize=4096 ascii-ci=0 ftype=0 > > log =internal > > > > bsize=4096 blocks=6400, > > version=2 > > = > > > > sectsz=512 sunit=64 blks, > > lazy-count=1 > > realtime =none > > > > extsz=4096 blocks=0, > > rtextents=0 > > > > Eu nu vad nicio diferenta care sa ma duca cu gandul la > > diferenta aceasta imensa de la 52milioane de inoduri vs > > 80mii inoduri. > > -------------------------------------------- > > On Tue, 7/26/16, Cristian Paslaru <[email protected]> > > wrote: > > > > Subject: Re: [rlug] partition 100% full No space left > on > > device > > To: "lista email" <[email protected]>, > > "Romanian Linux Users Group" <[email protected]> > > Date: Tuesday, July 26, 2016, 3:38 PM > > > > Ce isize > > ai la /?Default e 256, si daca ai asa putine inodes > > avail, este posibil sa ai un isize huge, hence your > > issue. > > Incearca > > xfs_info / > > Sporuri. > > > > 2016-07-26 14:26 GMT+03:00 > > lista email <[email protected]>: > > am scris in primul email, un raport > > complet. > > > > > > > > Da, inoduri mai sunt, dar tocmai aici este diferenta! > > > > > > > > Pe nodul seek: > > > > # df -i|grep root > > > > /dev/mapper/centos-root 77104 66220 > 10884 > > 86% / > > > > > > > > pe nodul ok: > > > > # df -i|grep root > > > > /dev/mapper/centos-root > > 52424704 66137 52358567 1% / > > > > > > > > Ambele au partitias / de 50GB! > > > > > > > > Dupa cate se poate observa, pe nodul ok sunt peste 52 > > milioane de inoduri in timp ce pe cel cu fs-ul full > sunt > > in > > jur de 77K. Cum se explica aceasta diferenta de > indouri > > pentru doua partitii cu aceeasi dimensiune? Din acest > > motiv, > > Wofly cat si Bogdan au avansat idea uni xfs corupt > catre > > care incep si eu sa inclin ... > > > > > > > > -------------------------------------------- > > > > On Tue, 7/26/16, Matei, > > Petre-Marius <[email protected]> > > wrote: > > > > > > > > Subject: Re: [rlug] partition 100% full No space left > on > > device > > > > To: [email protected] > > > > Date: > > Tuesday, July 26, 2016, 1:06 PM > > > > > > > > On 26.07.2016 12:07, > > > > Bogdan-Stefan Rotariu wrote: > > > > > On 26 July > > > > 2016 at 12:04:08, lista email ([email protected]) > > > > wrote: > > > > > > > > > > Buna > > > > tuturor, > > > > > > > > > > Neata, > > > > > > > > > > Ma uit de cateva zile > > > > peste un centos 7 si nu reusesc sa-mi dau seama de ce > df > > imi > > > > raporteaza ca partitia / este ~100% full iar du imi > > > > raporteaza usage de numai 1.7G din 50GB (adica sub > 4%). > > > > Mentionez ca partitia / este formatata xfs. > > > > > > > > > > > > > > > > > > > > Probabil ai o > > > > aplicatie care tine un fisier deschis, desi el nu > mai > > exista > > > > vizibil in fs. > > > > > > > > > > > > > > lsof -nP | grep '(deleted)’ > > > > > > > > > > sau cu listing mai ‘fancy’: > > > > > > > > > > find /proc/*/fd -ls | > > > > grep '(deleted)' > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > RLUG mailing list > > > > > [email protected] > > > > > http://lists.lug.ro/mailman/listinfo/rlug > > > > > > > > dar inoduri mai sunt? > > > > > > > > df -i > > > > > > > > Marius > > > > > > > > > > > > _______________________________________________ > > > > RLUG mailing list > > > > [email protected] > > > > http://lists.lug.ro/mailman/listinfo/rlug > > > > _______________________________________________ > > > > RLUG mailing list > > > > [email protected] > > > > http://lists.lug.ro/mailman/listinfo/rlug > > > > > > > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
