Dacă ai verificat vreodată dimensiunea fișierelor din /proc, probabil ai dat peste kcore și te-ai speriat: un singur fișier de peste 100 TB, pe o mașină cu doar câțiva gigabytes de memorie instalată. Nu e o eroare și nu ai un program malițios care umflă discul. E un comportament normal al kernelului Linux, dar merită explicat, pentru că întrebarea revine constant.
/proc nu e stocare reală
Tot ce se află sub /proc este virtual. Kernelul generează conținutul acestor fișiere în momentul citirii, nu le are stocate nicăieri pe disc. Din acest motiv, comenzi ca du sau df nu arată spațiu ocupat de /proc, iar un backup clasic (cp, rsync, tar) nu are ce să copieze cu adevărat - încearcă să citească o structură generată dinamic, nu date persistente.
Ce reprezintă kcore
kcore este un fișier special care expune memoria kernelului sub forma unui fișier ELF core. Practic e o fereastră către spațiul de adrese al kernelului, folosită de unelte de debugging precum gdb, împreună cu un binar de kernel nedecupat (/usr/src/linux/vmlinux), pentru a inspecta structuri de date din kernel în timp real.
De unde vine dimensiunea uriașă
Pe un sistem x86-64, dimensiunea raportată nu reflectă RAM-ul fizic instalat, ci întregul spațiu de adrese virtuale pe care kernelul îl poate teoretic ocupa. Pe majoritatea sistemelor x86-64 se vede o valoare fixă, indiferent dacă mașina are 4 GB sau 256 GB RAM instalat:
140.737.471.594.496 bytes (aprox. 128 TB)
Această cifră nu e aleatoare, rezultă din trei componente:
- 2^47 = 140.737.488.355.328 - pe x86-64, kernelul ocupă jumătatea superioară a spațiului de adrese pe 48 de biți. Zona de kernel începe la adresa 0xFFFF800000000000, ceea ce dă exact 2^47 bytes, adică 128 TB.
- -2^24 = -16.777.216 - primii 16 MB din acest spațiu (0xFFFF800000000000 până la 0xFFFF800000FFFFFF) sunt nemapați intenționat, ca zonă de gardă, pentru a prinde eventuale accesări greșite de pointeri la granița dintre spațiul utilizator și cel de kernel.
- +2^14 = +16.384 - un mic adaos care reflectă header-ul ELF și metadatele de segment pe care kcore le adaugă la începutul fișierului, pentru ca acesta să fie un fișier ELF valid.
Suma acestor trei termeni dă exact valoarea de mai sus. Pe arhitecturi diferite, cifra variază: pe aarch64, spre exemplu, dimensiunea raportată e alta, pentru că împărțirea spațiului de adrese pe 48 de biți diferă puțin.
Pe scurt: dimensiunea nu are legătură cu memoria fizică instalată, ci cu limita teoretică de adresare pe 64 de biți.
De ce nu are sens backup
Pornind de la discuția care a generat acest articol, în care s-a pus întrebarea dacă merită backup la kcore: răspunsul scurt e nu, din câteva motive:
- Conținutul e generat dinamic la citire și dispare complet la reboot - un backup ar “salva” o stare de memorie care oricum nu poate fi restaurată coerent.
- Dimensiunea raportată nu corespunde cu date reale de citit - o comandă cp sau o arhivare cu tar.gz fie ar dura enorm încercând să parcurgă un spațiu de adrese uriaș și parțial nemapat, fie ar eșua direct.
- Nu doar kcore, ci întregul /proc ar trebui exclus din orice strategie de backup. Alături de /proc, aceeași regulă se aplică și pentru /sys (informații despre hardware, tot virtual), /dev (noduri de dispozitiv, populate dinamic), /run (informații de sistem de la ultima pornire) și, de regulă, /tmp.
Pentru sisteme immutable, unde unelte ca Timeshift sau Borg nu funcționează la fel de bine ca pe un filesystem clasic, soluția corectă nu e să incluzi /proc în backup, ci să te asiguri că uneltele de backup exclud explicit aceste directoare virtuale și se concentrează pe date reale: /home, configurări din /etc, și eventual imaginea sistemului la nivel de pachete, nu la nivel de fișiere virtuale.
Concluzie
/proc/kcore e una dintre acele particularități ale Linux-ului care par o eroare la prima vedere, dar au o explicație tehnică clară odată ce înțelegi cum funcționează spațiul de adrese pe 64 de biți. Nu ocupă spațiu real pe disc, nu trebuie inclus în backup și, dacă apare cu o dimensiune mai mică decât limita teoretică, ar fi de fapt un motiv de îngrijorare, nu invers.
Discuție pornită în grupul Linux Romania, cu trimitere la un thread mai vechi de pe Ask Ubuntu care detaliază matematic dimensiunea fișierului.