Re: [rlug] partition 100% full No space left on device
SGI nu mai există de ceva ani. Așa că "cei de la xfs" sunt cei care mențin kernelul ăla. Cumva sistemul ăla a rămas fără alimentare ? "xfs is for speed not reliability :)" - dacă nu ai alimentare așa este. Haha atunci râmâi pe jfs/jfs2 că e mai bun :( O zi mai bună. On 07/27/2016 08:11 PM, Iulian Roman wrote: > 2016-07-27 12:06 GMT+02:00 lista email : > >> 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 wrote: >> >> Subject: Re: [rlug] partition 100% full No space left on device >> To: "lista email" >> Cc: "Romanian Linux Users Group" >> 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 : >> 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 nor
Re: [rlug] partition 100% full No space left on device
2016-07-27 12:06 GMT+02:00 lista email : > 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 wrote: > > Subject: Re: [rlug] partition 100% full No space left on device > To: "lista email" > Cc: "Romanian Linux Users Group" > 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 : > 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 > > wrote: > > > > Subject: Re: [rlug] partition 100% full No space left on > device > > To: "lista email" , > "Romanian Linux Users Group" , > "Cristian Paslaru" > > Date: Tuesday, July 26, 2016, 4:02 PM > > > > Nu e de la isize. Are valoarea
Re: [rlug] partition 100% full No space left on device
Salut Misu, Folosesc browserul web ca sa raspund la mesaje, nu am alta varianta. Sistemul este la distanta, nu am access fizic la el. HDD-ul nu e un simplu HDD ci o matrice raid (raid 1). Am si precizat ca mi-ar fi fost usor daca as fi putut accesa acel / offline (aici sunt diverse variante, inclusiv cea propusa de tine). Si nu ai inteles. Eu nu am facut o peratiune care a cauzat. L-am gasit "cauzat" :)) si am inceput sa investighez. Operatiunea am facut-o intentionat, ca verificare, dupa ce am descoperit ca numarul maxim de inoduri in partitia / difera foarte mult intre cele doua sisteme desi ele sunt identice (mergand pe principiul: daca partitia/geometria, etc sunt corecte si partitia / ocupa tot spatiul de 50GB in lvm asa cum rezulta din verificari, orice xfs_grow nu va avea niciun efect) ... Surprinzator ... a avut efect dar NUMAI asupra numarului maxim de inoduri disponibil pe acea partitie, acesta a crescut cu peste 20%!!! adica de la 66K la 85K in timp ce partitia a ramas tot de 50GB. Ulterior, numarul acestora a inceput sa scada ... lent, lent... pana cand astazi, s-a ajuns din nou la valoarea de 66k, adica exact cea de dinainte de a da xfs_grow. In tot acest timp, numarul de fisiere si numarul de inoduri folosite a ramas constant. Asta ma duce cu gandul (asa cum au mai precizat si alte persoane aici) ca e ceva in neregula cu xfs-ul. O sa vad zilele viitoare cum pot intra pe / sa-l pun offline ... exista variante ... ori mai implic o alta persoana in capatul celalalt ori primesc eu acces la un nivel superior. Intre timp, poate spun ceva si cei de la SGI. Deocamdata, nicio veste ... On Wed, 7/27/16, Mișu Moldovan wrote: Subject: Re: [rlug] partition 100% full No space left on device To: "lista email" , "Romanian Linux Users Group" Date: Wednesday, July 27, 2016, 1:46 PM On 26.07.2016 11:59, lista email wrote: > Buna tuturor, > > 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. […] Salut, Am încercat să urmăresc discuția asta, dar e greu cu clientul tău de mail ce rupe firele de discuție de câte ori răspunzi… Call me paranoid, dar ai verificat HDD-ul cu problema în alt sistem (deci cu un alt BIOS, presupus necompromis), pornind sistemul de pe un mediu read-only (CD/DVD) scris pe un sistem curat dintr-o imagine cu checksum verificat? Deși, dacă ar fi să pariez, aș merge fie pe un bug, fie pe un chițibuș XFS ce ne scapă nouă, posibil legat de acea operațiune ce ai făcut-o recent doar pe unul dintre sisteme… ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] partition 100% full No space left on device
On 26.07.2016 11:59, lista email wrote: > Buna tuturor, > > 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. […] Salut, Am încercat să urmăresc discuția asta, dar e greu cu clientul tău de mail ce rupe firele de discuție de câte ori răspunzi… Call me paranoid, dar ai verificat HDD-ul cu problema în alt sistem (deci cu un alt BIOS, presupus necompromis), pornind sistemul de pe un mediu read-only (CD/DVD) scris pe un sistem curat dintr-o imagine cu checksum verificat? Deși, dacă ar fi să pariez, aș merge fie pe un bug, fie pe un chițibuș XFS ce ne scapă nouă, posibil legat de acea operațiune ce ai făcut-o recent doar pe unul dintre sisteme… signature.asc Description: OpenPGP digital signature ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] partition 100% full No space left on device
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. 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 wrote: Subject: Re: [rlug] partition 100% full No space left on device To: "lista email" Cc: "Romanian Linux Users Group" 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 : 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 wrote: Subject: Re: [rlug] partition 100% full No space left on device To: "lista email" , "Romanian Linux Users Group" , "Cristian Paslaru" 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,
Re: [rlug] partition 100% full No space left on device
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 : > 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 wrote: > > Subject: Re: [rlug] partition 100% full No space left on device > To: "lista email" , "Romanian Linux Users Group" < > rlug@lists.lug.ro>, "Cristian Paslaru" > 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=0finobt=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 > 523585671% / > > # xfs_info / > meta-data=/dev/mapper/centos-root isize=256 > agcount=16, agsize=819136 blks > = > > sectsz=512 attr=2, > projid32bit=1 > = > > crc=0finobt=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 > wrote: > > Subject: Re: [rlug] partition 100% full No space left on > device > To: "lista email" , > "Romanian Linux Users Group" > 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 : > 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 ce
Re: [rlug] partition 100% full No space left on device
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 wrote: Subject: Re: [rlug] partition 100% full No space left on device To: "lista email" , "Romanian Linux Users Group" , "Cristian Paslaru" 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 wrote: Subject: Re: [rlug] partition 100% full No space left on device To: "lista email" , "Romanian Linux Users Group" 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 : 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 wrote: Subject: Re: [rlug] partition 100% full No space left on device To: rlug@lists.lug.ro 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 (lista.em...@yahoo.com) wrote: > > Buna tuturor, > >
Re: [rlug] partition 100% full No space left on device
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=256agcount=17, agsize=819136 blks = sectsz=512 attr=2, projid32bit=1 = crc=0finobt=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 523585671% / # xfs_info / meta-data=/dev/mapper/centos-root isize=256agcount=16, agsize=819136 blks = sectsz=512 attr=2, projid32bit=1 = crc=0finobt=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 wrote: Subject: Re: [rlug] partition 100% full No space left on device To: "lista email" , "Romanian Linux Users Group" 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 : 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 wrote: Subject: Re: [rlug] partition 100% full No space left on device To: rlug@lists.lug.ro 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 (lista.em...@yahoo.com) 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 > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug dar inoduri mai sunt? df -i Marius ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] partition 100% full No space left on device
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 : > 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 523585671% / > > 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 wrote: > > Subject: Re: [rlug] partition 100% full No space left on device > To: rlug@lists.lug.ro > 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 (lista.em...@yahoo.com) > 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 > > RLUG@lists.lug.ro > > http://lists.lug.ro/mailman/listinfo/rlug > > dar inoduri mai sunt? > > df -i > > Marius > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] partition 100% full No space left on device
:) buna observatia aceasta, dar nici asta nu se verifica. # mount|grep ^/ /dev/mapper/centos-root on / type xfs (rw,relatime,attr2,inode64,logbsize=256k,sunit=512,swidth=512,noquota) /dev/sda1 on /boot type xfs (rw,relatime,attr2,inode64,logbsize=256k,sunit=512,swidth=512,noquota) /dev/mapper/centos-home on /home type xfs (rw,relatime,attr2,inode64,logbsize=256k,sunit=512,swidth=512,noquota) # deci avem /, /home si /boot, toate sunt xfs. # umount /home/ # ls /home/ # du -sh /home/ 0 /home/ # mount /home/ # du -sh /boot/ 104M/boot/ # umount /boot/ # du -sh /boot/ 0 /boot/ # mount /boot/ # Ipoteza avansata nu se verifica. numai / nu pot sa-l demontez si nu sunt ferm convins ca procesele sunt totusi in regula ... Daca as putea boota cu un disk ceva sa am partitia / offline, m-as lamuri repede ce e cu / dar sunt via ssh ... On Tue, 7/26/16, Alexandru Cucu wrote: Subject: Re: [rlug] partition 100% full No space left on device To: "lista email" , "Romanian Linux Users Group" Date: Tuesday, July 26, 2016, 2:37 PM Salut, Vezi ce partitii ai montate. Probabil candva nu ti s-a montat vreo partitie, ai scris pe root, apoi cand ai remontat partitia ai montat in folder cu date. --- Alex Cucu 2016-07-26 14:26 GMT+03:00 lista email : > 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 wrote: > > Subject: Re: [rlug] partition 100% full No space left on device > To: rlug@lists.lug.ro > 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 (lista.em...@yahoo.com) > 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 > > RLUG@lists.lug.ro > > http://lists.lug.ro/mailman/listinfo/rlug > > dar inoduri mai sunt? > > df -i > > Marius > > > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > ___ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] partition 100% full No space left on device
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 523585671% / 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 wrote: Subject: Re: [rlug] partition 100% full No space left on device To: rlug@lists.lug.ro 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 (lista.em...@yahoo.com) 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 > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug dar inoduri mai sunt? df -i Marius ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] partition 100% full No space left on device
1. s-a dat reboot, problema a ramas 2. nu am access la server decat via ssh 3. s-a verificat de rootkit, am scris asta in primul mesaj. dmesg e oprit . cu mesajul rhel-dmesg[1055]: dmesg: write failed: No space left on device. l-am pornit eu acum. Scrie ~10 randuri in messeges, dupa care apare: tail: /var/log/messages: file truncated ... si in noul fisier nu mai apare nimic. Am mentionat in primul mesaj ca diferenta majora intre cele doua sisteme este numarul de inoduri maxim disponibile in partitia /: sunt 52 milioane pe serverul 0k si numai 80.000 pe cel seek. On Tue, 7/26/16, Alex 'CAVE' Cernat wrote: Subject: Re: [rlug] partition 100% full No space left on device To: "Romanian Linux Users Group" Date: Tuesday, July 26, 2016, 1:06 PM On 26/7/2016 12:07 PM, Bogdan-Stefan Rotariu wrote: > 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)' 1. daca poti sa dai reboot, da-i; o fi 'windozareala', dar de multe ori rezolva, inclusiv in cazul in care e un fisier deschis si neinchis; daca nu poti, poti sa incerci solutia de mai sus a colegului 2. daca nici dupa reboot nu se rezolva problema, booteaza in init 1 si da-i un fsck fortat; nu cred ca am vazut xfs dus in craci pana acum, insa tocmai ce-am patit pe un mega legacy de reiserfs care a luat-o frumos pe camp, fara rebuild-tree nu a vrut sa discute 3. asta presupunand ca ai ceva carcalaci pe server, care ti-ar ascunde niste fisiere; nu e neaparat exclus, dar mult mai probabil ar fi situatiile 1 si 2; sau poate pur si simplu ti-a scapat ceva vreun director atunci cand ai verificat presupun ca pe host / storage mai e spatiu, oricum in cazul asta ar fi trebuit sa ploua prin dmesg cu erori Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] partition 100% full No space left on device
On 07/26/2016 01:24 PM, Valentin Cozma wrote: > am avut o singura data o problema similara, de la un server de vnc > always on . > > Daca reporneam serverul de vnc isi revenea spatiul . Am facut un script > de-i da restart periodic. windowsarule ! aveai un ceva care stergea ( sau rotea ) loguri fara sa dea sighup aplicatiei care le genera. iar in cazul de fata nu se aplica, omul a spus ca problema persista dupa reboot. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] partition 100% full No space left on device
am avut o singura data o problema similara, de la un server de vnc always on . Daca reporneam serverul de vnc isi revenea spatiul . Am facut un script de-i da restart periodic. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] partition 100% full No space left on device
On 26/7/2016 12:07 PM, Bogdan-Stefan Rotariu wrote: > 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)' 1. daca poti sa dai reboot, da-i; o fi 'windozareala', dar de multe ori rezolva, inclusiv in cazul in care e un fisier deschis si neinchis; daca nu poti, poti sa incerci solutia de mai sus a colegului 2. daca nici dupa reboot nu se rezolva problema, booteaza in init 1 si da-i un fsck fortat; nu cred ca am vazut xfs dus in craci pana acum, insa tocmai ce-am patit pe un mega legacy de reiserfs care a luat-o frumos pe camp, fara rebuild-tree nu a vrut sa discute 3. asta presupunand ca ai ceva carcalaci pe server, care ti-ar ascunde niste fisiere; nu e neaparat exclus, dar mult mai probabil ar fi situatiile 1 si 2; sau poate pur si simplu ti-a scapat ceva vreun director atunci cand ai verificat presupun ca pe host / storage mai e spatiu, oricum in cazul asta ar fi trebuit sa ploua prin dmesg cu erori Alex ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] partition 100% full No space left on device
On 26.07.2016 12:07, Bogdan-Stefan Rotariu wrote: > On 26 July 2016 at 12:04:08, lista email (lista.em...@yahoo.com) 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 > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug dar inoduri mai sunt? df -i Marius ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] partition 100% full No space left on device
Buna, lsof nu raporteaza nimic :( [root@a alx_test]# lsof -nP | grep '(deleted)' [root@a alx_test]# find /proc/*/fd -ls | grep '(deleted)' altceva trebuie sa fie ... On Tue, 7/26/16, Bogdan-Stefan Rotariu wrote: Subject: Re: [rlug] partition 100% full No space left on device To: rlug@lists.lug.ro Date: Tuesday, July 26, 2016, 12:07 PM On 26 July 2016 at 12:04:08, lista email (lista.em...@yahoo.com) 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 RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] partition 100% full No space left on device
On 26 July 2016 at 12:04:08, lista email (lista.em...@yahoo.com) 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 RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
[rlug] partition 100% full No space left on device
Buna tuturor,
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.
# df -a|grep ^/
/dev/mapper/centos-root 52403200 52400396 2804 100% /
^^ ^^
/dev/sda1 503040 131876371164 27% /boot
/dev/mapper/centos-home 21052979235204 210494588 1% /home
Du imi arata insa ca nu folosesc pe / mai mult de 1.7G
# du -sch /* --exclude=home --exclude=boot
0 /bin
0 /dev
25M /etc
0 /lib
0 /lib64
744K/luarocks-2.3.0
0 /media
0 /mnt
125M/openresty-1.9.7.4
0 /opt
420K/root
49M /run
0 /sbin
0 /srv
0 /sys
0 /tmp
1.3G/usr
227M/var
1.7Gtotal
[root@localhost ~]#
M-am gandit la inoduri dar aici am 80% usage.
# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/centos-root 78160 66218 11942 85% /
devtmpfs 8218272 519 82177531% /dev
tmpfs 8221010 1 82210091% /dev/shm
tmpfs 8221010 648 82203621% /run
tmpfs 822101013 82209971% /sys/fs/cgroup
/dev/sda1 509952 3305096221% /boot
/dev/mapper/centos-home 21063270499 2106326051% /home
tmpfs 8221010 1 82210091% /run/user/0
#
Partitia / este creata peste un LVM, care si el este de 50GB, adica ok.
# lvdisplay /dev/centos/root
--- Logical volume ---
LV Path/dev/centos/root
LV Nameroot
VG Namecentos
LV Status available
# open 1
LV Size50.00 GiB
Current LE 12800
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0
Am verificat sa nu fie vreun rootkit, nu am gasit nimic.
Mai am un sistem identic cu acesta unde df raporteaza corect si singura
diferenta care am gasit-o intre cele doua sisteme este la numarul maxim de
inoduri in partitia radacina (care in ambele cazuri este la fel, 50GB!!!):
# df -i|grep ^/
/dev/mapper/centos-root 52424704 66137 523585671% /
^
/dev/sda1 509952 3305096221% /boot
/dev/mapper/centos-home 21063270426 2106326781% /home
[root@localhost ~]#
Am cautat sa vad numarul de fisiere existente pe ambele servere si este similar
~180K.
Cautand fisere mai mari de 100M pe /, am gasit numai unul, de 104M pe ambele
servere (acelasi):
find / -type f -size +10k -exec ls -lh {} \;
#
/usr/lib/locale/locale-archive
#
Cautand fisere mai mari de 10M, am gasit sub 20 (la fel pe ambele servere),
deci nu este de la fisiere.
# find / -type f -size +1k -exec ls -lh {} \; |wc -l
16
#
In ambele cazuri, in partitia / numarul utilizat de inoduri este in jur de 66K.
Pana si xfs_info este identic pe ambele servere pentru /. Ceea ce difera este
numarul maxim de inoduri raportat de df: 85k (la serverul cu / full) fata de
52milioane (la serverul care raporteaza corect, 1% usage).
De unde sa fie oare? m-am uitat la xfs_grow si vad ca nu am nicio optiune (cu
exceptia -m care nu ma intereseaza) pentru a mari numarul de inoduri pastrand
neschimbata dimensiunea / la 50GB. Cum este posibil ca pe un sistem sa am un
numar maxim de inoduri de 85k iar pe altul de 52milioane pentru o partitie xfs
de 50GB in ambele cazuri? Ce imi scapa?
Multumesc,
Alex
___
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug
