Permalänk
Medlem

Rpi 3 kali linux inodes

Hej!

Har en raspberry pi 3b+ som jag kör kali linux på. Igår skulle jag uppdatera den då visade det sig att alla inodes var upptagna så jag satte mig och googla lite. Hittade lite tips på hur man kunde gör för att leta efter de och hittade vad som tog upp de flesta inodsen och de ligger 538730 i /var/cache/fontconfig men jag lyckades aldrig hitta hur jag blir av med dem.. De flesta tipsen gick ut på att ta bort filerna som tog plats men man kan ju inte bara ta bort mappen för då slutar ju allt fungera. Har testat att installera om fontconfig och bygga om cachen men det fungera inte heller. Någon som har nåt tips på vart jag ska börja? det är tredje gången den gör såhär och de två andra gångerna har jag installerat om

//Daniel

Permalänk
Medlem

Över en halv miljon filer för fonter låter lite fel - låter som någon script/program som har gått galet och bara skapar och skapar. - det är väldigt sällsynt annars att man kör slut på just Inoder och en del moderna filsystem som BTRFS så händer det inte då den delen kan utökas obegränsat

Är det tomma filer (0 bytes)? - även relativ små filer gånger halv miljon borde ha synts i form av förbrukad diskplats

Till detta så brukar det som läggs i cache/temp direktorys vara av typen filer som kan raderas då 'cache' är bara till för att snabba upp hämtning av tex en font och finns det inte så genereras filen igen vid behov för att inläsing nästa gång skall gå fortare.

Permalänk
Skrivet av lilldeck:

Hittade lite tips på hur man kunde gör för att leta efter de och hittade vad som tog upp de flesta inodsen och de ligger 538730 i /var/cache/fontconfig men jag lyckades aldrig hitta hur jag blir av med dem.. De flesta tipsen gick ut på att ta bort filerna som tog plats men man kan ju inte bara ta bort mappen för då slutar ju allt fungera. Har testat att installera om fontconfig och bygga om cachen men det fungera inte heller. Någon som har nåt tips på vart jag ska börja?

En halv miljon upptagna inoder låter onormalt, vad är det egentligen som ligger där? Har du oerhörda mängder typsnitt installerade? Har du kört fc-cache med flaggan "-r"? Om du säger "sudo fc-cache -rfv", vad svarar din hallonpaj då?

Permalänk
Medlem
Skrivet av xxargs:

Över en halv miljon filer för fonter låter lite fel - låter som någon script/program som har gått galet och bara skapar och skapar. - det är väldigt sällsynt annars att man kör slut på just Inoder och en del moderna filsystem som BTRFS så händer det inte då den delen kan utökas obegränsat

Är det tomma filer (0 bytes)? - även relativ små filer gånger halv miljon borde ha synts i form av förbrukad diskplats

Till detta så brukar det som läggs i cache/temp direktorys vara av typen filer som kan raderas då 'cache' är bara till för att snabba upp hämtning av tex en font och finns det inte så genereras filen igen vid behov för att inläsing nästa gång skall gå fortare.

root@kali-pi:~# ls -ahl /var/cache/
totalt 46M
drwxr-xr-x 15 root root 4,0K okt 28 18:36 .
drwxr-xr-x 13 root root 4,0K okt 28 19:12 ..
drwxr-xr-x 3 root root 4,0K mar 15 2016 apache2
drwxr-xr-x 3 root root 4,0K nov 22 14:13 apt
drwxr-xr-x 2 root root 4,0K nov 9 18:34 debconf
drwxr-xr-x 2 root root 4,0K mar 15 2016 dictionaries-common
drwxr-xr-x 2 root root 46M nov 23 20:25 fontconfig
drwxr-xr-x 2 root root 4,0K sep 2 14:32 fonts
drwx------ 2 root root 4,0K nov 22 12:59 ldconfig
drwx--x--x 3 root root 4,0K sep 23 04:25 lightdm
drwxr-xr-x 2 root root 4,0K nov 23 06:26 locate
drwxr-xr-x 41 man man 4,0K nov 23 06:26 man
drwxr-xr-x 3 root root 4,0K maj 31 2016 postgresql
drwx------ 2 root root 4,0K sep 23 02:31 private
drwxr-xr-x 2 root root 4,0K mar 9 2016 samba

så 46M stor är katalogen men det känns som att det är något program/script som gör något
har en asus tinkerboard som också kör kali och den har inga problem
i grunden ligger ju debian stretch

Skrivet av Hieronymus Bosch:

En halv miljon upptagna inoder låter onormalt, vad är det egentligen som ligger där? Har du oerhörda mängder typsnitt installerade? Har du kört fc-cache med flaggan "-r"? Om du säger "sudo fc-cache -rfv", vad svarar din hallonpaj då?

https://pastebin.com/JqkbCnNU svara den,
Har inte installerat några typsnitt mer än de som följer med xfce
så heter filerna
-rw-r--r-- 1 root root 88 nov 9 22:25 190416e9-7148-4bb4-8820-8150a4b43251-le32d8.cache-7
-rw-r--r-- 1 root root 88 nov 1 22:23 1904270b-6eef-493b-a016-e7f75bbb338e-le32d8.cache-7
-rw-r--r-- 1 root root 80 nov 1 17:11 190428e6-8a8f-45bc-b241-21de8aec52a8-le32d8.cache-7
-rw-r--r-- 1 root root 80 nov 9 18:09 190432cd-df9e-4e82-b25a-e21f6cd8e73f-le32d8.cache-7
-rw-r--r-- 1 root root 96 nov 9 20:50 190437ae-77bd-4239-8c8d-41bee95d0981-le32d8.cache-7
-rw-r--r-- 1 root root 80 nov 9 21:07 19044700-8458-4777-a80d-ba948c608c43-le32d8.cache-7

Permalänk
Skrivet av lilldeck:

root@kali-pi:~# ls -ahl /var/cache/
totalt 46M

Hmm, det där är väl bara storleken på själva katalogerna (alltså listan med filer, typ), inte deras innehåll?
Om du säger
du -sh /var/cache/*
får du ut storleken på hela innehållet i varje underkatalog till /var/cache.

Jag har ingen framgång med "r"-flaggan till fc-cache på Kali. Oavsett om jag kör fc-cache med eller utan "-r" så växer innehållet i /var/cache/fontconfig varje gång jag kör fc-cache.

Jag har testat att nuka allt i fontconfig
(rm -rf /var/cache/fontconfig/*) och därefter återskapa cachen (fc-cache -v), vilket leder till att antalet filer i /var/cache/fontconfig krymper dramatiskt. Jag har inte upptäckt några otrevliga bieffekter, men det kan ju vara bra att backa upp innehållet i /var/cache/fontconfig (till ett tar-arkiv, så att det inte förbrukar så många inoder...) innan du börjar städa.

Permalänk
Medlem

Brukar inte /var/cache nukas var gång dator startar ?? - det är sådant + en del annat som också gärna flyttas till RAM-minne virtuell filsystem för att minska slitage på SD-kortet i grejor som är tänkta att rulla lång tid oövervakat.

om du inte kör grafisk miljö utan enbart via SSH så är inte behovet speciellt stor av fontcache - så man kan fråga varför det spinner loss och genererar filer hela tiden - och en halv miljon filer på 46 MB ger ca 90 Byte per fil i fillistan (direktoryt) och i ext4 allokeras minst 4096 byte per fil även om man bara skriver en byte i filen och med dryga halvmiljonen filer då skulle ta minst 2 GB på disken och det borde synas på din kvarvarande diskutrymme - om det inte syns att det käkat mycket diskutrymme så är det många 0-bytes filer också och då kan man fundera vidare varför det är så...

till detta:

sitter program hela tiden och gör nya filer för fonter (även 0-bytes filer) så uppdateras metadatat och journalen hela tiden med stor writing amplication och en utsliten SD i förtid - och dagens SD i låga prissegmentet och det man ser i gubbdagisar, kontorsvaruhadlarna och datorbutiker är inte speciellt skrivtålbara i antalet P/E-cykler - sektorreallokering och sektor-recykling tveksam pga. enklare kontrollogik (i jämförelse med SSD) då det är ofta bland det är nedre skiktet av binningen av flash-minne från tillverkningen. Kort sagt säljbar avfallshantering av minnen som ingen annan vill köpa för SSD eller inbyggnad etc. istället för direkt destruktion...

Permalänk
Medlem
Skrivet av Hieronymus Bosch:

Hmm, det där är väl bara storleken på själva katalogerna (alltså listan med filer, typ), inte deras innehåll?
Om du säger
du -sh /var/cache/*
får du ut storleken på hela innehållet i varje underkatalog till /var/cache.

Jag har ingen framgång med "r"-flaggan till fc-cache på Kali. Oavsett om jag kör fc-cache med eller utan "-r" så växer innehållet i /var/cache/fontconfig varje gång jag kör fc-cache.

Jag har testat att nuka allt i fontconfig
(rm -rf /var/cache/fontconfig/*) och därefter återskapa cachen (fc-cache -v), vilket leder till att antalet filer i /var/cache/fontconfig krymper dramatiskt. Jag har inte upptäckt några otrevliga bieffekter, men det kan ju vara bra att backa upp innehållet i /var/cache/fontconfig (till ett tar-arkiv, så att det inte förbrukar så många inoder...) innan du börjar städa.

Jo det är sant ls -shl visar ju bara katalog storleken
du -sh /var/cache/* visade 2,2G
Testade att ta bort katalogen och sen köra fc-cache -v vilket minska den väldigt mycket nu använder den 42 inodes
men nu är ju frågasn om det kommer att bli lika mycket igen eller om den stannar kvar på så få..för fortsätter den öka är ju något väldigt fel

Skrivet av xxargs:

Brukar inte /var/cache nukas var gång dator startar ?? - det är sådant + en del annat som också gärna flyttas till RAM-minne virtuell filsystem för att minska slitage på SD-kortet i grejor som är tänkta att rulla lång tid oövervakat.

om du inte kör grafisk miljö utan enbart via SSH så är inte behovet speciellt stor av fontcache - så man kan fråga varför det spinner loss och genererar filer hela tiden - och en halv miljon filer på 46 MB ger ca 90 Byte per fil i fillistan (direktoryt) och i ext4 allokeras minst 4096 byte per fil även om man bara skriver en byte i filen och med dryga halvmiljonen filer då skulle ta minst 2 GB på disken och det borde synas på din kvarvarande diskutrymme - om det inte syns att det käkat mycket diskutrymme så är det många 0-bytes filer också och då kan man fundera vidare varför det är så...

till detta:

sitter program hela tiden och gör nya filer för fonter (även 0-bytes filer) så uppdateras metadatat och journalen hela tiden med stor writing amplication och en utsliten SD i förtid - och dagens SD i låga prissegmentet och det man ser i gubbdagisar, kontorsvaruhadlarna och datorbutiker är inte speciellt skrivtålbara i antalet P/E-cykler - sektorreallokering och sektor-recykling tveksam pga. enklare kontrollogik (i jämförelse med SSD) då det är ofta bland det är nedre skiktet av binningen av flash-minne från tillverkningen. Kort sagt säljbar avfallshantering av minnen som ingen annan vill köpa för SSD eller inbyggnad etc. istället för direkt destruktion...

Jo det ska den göra men det verkar inte fungera som det ska det heller för allt finns kvar i katalogen vid omstart.
Kör vnc ibland för vissa saker men det kanske går väl lösa så man slipper att ha X igång hela tiden.Men något
ska testa och köra en vecka nu och se hur mycket den ökar igen annars skippar jag X