De ce actualizarea kernel-ului de astăzi are nevoie de o jumătate de gigabyte de spațiu pe disc?

Am primit o notificare de actualizări la Ubuntu 20.04. Verific întotdeauna lista de actualizări pentru a decide cât de serioasă trebuie să fac o copie de rezervă înainte de actualizare. Actualizarea de astăzi a nucleului (5.13.0.28.31~20.04.15) are nevoie de o jumătate de gigabyte de spațiu suplimentar pe disc:

$ sudo apt upgrade 
...
Următoarele pachete NOI vor fi instalate:
  linux-headers-5.13.0-28-generic linux-hwe-5.13-headers-5.13.0-28
  linux-image-5.13.0-28-generic linux-module-5.13.0-28-generic
  linux-module-extra-5.13.0-28-generic
Următoarele pachete vor fi actualizate:
  linux-generic-hwe-20.04 linux-headers-generic-hwe-20.04
  linux-image-generic-hwe-20.04 linux-libc-dev
4 pentru a face upgrade, 5 pentru a instala nou, 0 pentru a renova și 0 pentru a nu face upgrade
Trebuie să obțineți 95,0 MB de arhive.
Dupa aceasta operatie, Se vor folosi 508 MB de spațiu suplimentar pe disc.

Știu că Ubuntu permite mai multe nuclee să coexiste, așa că acest nucleu trebuie să folosească spațiu proaspăt pe disc, în loc să înlocuiască software-ul existent, dar încă pare mare. Nu am ținut note, dar am crezut că o actualizare a nucleului este de obicei de câteva sute de MB.Nu am observat niciodată dimensiunea nucleelor ​​înainte sau există ceva neobișnuit în actualizarea de astăzi?

Aici se întâmplă câteva lucruri diferite, în funcție de curiozitatea ta...

Actualizările kernel-urilor sunt livrate ca pachete autonome, nu simple upgrade

Majoritatea sistemului dumneavoastră este împachetat în așa fel încât atunci când este extrasă o actualizare, aceasta înlocuiește ultima versiune. Kernel-urile sunt ambalate cu versiunea lor în numele pachetului. Acest lucru vă oferă posibilitatea de a reveni la o versiune anterioară dacă ceva nu merge bine.

Nu trebuie să păstrați sâmburii vechi în preajmă. De îndată ce știți că cel nou funcționează, le puteți elimina pe cele vechi. sudo apt autoremove va face acest lucru pentru dvs., dar asigurați-vă că noua versiune funcționează mai întâi.

Sâmburi sunt mare (și devin mai mari)

Deci am stabilit de ce instalarea unui nucleu actualizat ocupă spațiu suplimentar, dar de ce atâta spaţiu?

Ubuntu oferă un nucleu construit pentru o selecție largă de hardware. Canonical vrea să funcționeze doar⢠atunci când conectați lucrurile. Fiecare versiune minoră are mai multe drivere adăugate la ea. Rata șoferilor vechi care sunt eliminate este de obicei mult mai lent.

Deci, în timp, ne așteptăm ca miezul să înflorească în dimensiune. Bionic 4.15.0-101.102 are aproximativ 60% dimensiunea lui Focal HWE 5.13.0. Acest lucru este exprimat în mare parte prin faptul că au mai puține module, în special în module-extra.

eu îmi place să consider asta ca un progres. Spațiul pe disc și lățimea de bandă sunt ieftine pentru majoritatea dintre noi, așa că este logic să acordați prioritate suportului pentru drivere. Nu cred că ceea ce vedem aici este anormal.

Dar de ce sunt pachetele lor atât de mici? Cum o descărcare de 94 MB ocupă 508 MB de spațiu pe disc?

Se comprimă [foarte] bine. Puteți vedea acest lucru descărcând pachetele și folosind puțin scripting pentru a expune dimensiunea lor dezambalată.

• Obțineți pachetele: apt download linux-generic-hwe-20.04 linux-headers-generic-hwe-20.04 linux-image-generic-hwe-20.04 linux-headers-5.13.0-28-generic linux-hwe-5.13-headers-5.13.0- 28 linux-image-5.13.0-28-generic linux-module-5.13.0-28-generic linux-module-extra-5.13.0-28-generic
• Comparați dimensiunea lor „fizică” cu dimensiunea conținutului lor: pentru f în *.deb; do stat --printf="%5n\t%s\t" "$f"; dpkg -c $f; Terminat

E destul de crud în acel moment. Îl puteți introduce în Calc pentru a afișa totalurile și procentele:

Puțin mai mult de 508 MB de spațiu pe disc combinate (și înainte de DKMS), dar poate că ați avut deja unele dintre pachete descărcate. În orice caz, puteți vedea că unele pachete sunt masiv mai mari.

Vreau sâmburi mai mici!

Și le poți avea. Doar privind în jos modulele-conținutul pachetului suplimentar, pot vedea sute de megaocteți de lucruri de care nu am nevoie. Din păcate, sunt unele de care am nevoie totuși.

Tu poate sa (destul de ușor) construiți-vă propriile Kernel-uri. Există scripturi de compilare (folosesc în prezent linux-tkg). Are 450 MB pe disc în acest moment, dar l-aș putea rula printr-un ajutor ca face localmodconfig pentru a reduce modulele construite doar la lucrurile încărcate în prezent. Acest lucru ar elimina aproximativ 95% din module.

Problema cu această abordare este că necesită timp CPU și timpul meu pentru ao actualiza atunci când există actualizări. Esti pe cont propriu. Majoritatea oamenilor sunt mai bine cu nucleul întreținut.

Toate cele de mai sus sunt absolut adevărate.

Cu toate acestea, o parte a răspunsului (și de ce funcționează răspunsurile de mai sus), se bazează pe modul în care Linux gestionează un fișier „șters” - nu într-adevăr să fie șters până când se termină tot ce îl folosește.

Exemplu:
Să presupunem că există o aplicație, „Super Duper Text Editor” și, de asemenea, să presupunem că aveți mai multe ferestre deschise cu textul pe care îl editați.

În plus, presupunem că se instalează o actualizare a Super Duper Text Editor. Sesiunile dvs. de editare existente nu sunt blocate imediat, ci dispar după ce le închideți.

Ca aceasta:

1. Aveți mai multe instanțe ale editorului de text deschise.
2. Îl actualizezi.
   • Actualizatorul „deconectează” intrarea din director la fișierul vechi (sau o recreează) și adaugă o legătură către noul fișier, cu intrarea inițială a directorului marcată ca „ștersă”
   • Linkurile existente către sesiunile dvs. rămân până când sesiunile existente sunt închise.
3. Toate fișierele noi sunt adăugate, dar fișierele existente care sunt încă în uz nu sunt distruse deoarece sunt încă în uz.
4. În cele din urmă, pe măsură ce salvați munca și închideți ferestrele, numărul de link-uri active către fișierele vechi scade la zero. (rețineți că linkul directorului a fost eliminat când pachetul a fost actualizat.)

Când numărul de legături către un fișier scade la zero, se presupune că fișierul este „șters” și că spațiul este recuperat pentru reutilizare de către sistemul de fișiere și marcat ca disponibil în superbloc și/sau bitmap de volum.

În cele din urmă, (sau mai ales după o repornire), toate fișierele vechi au zero link-uri și sunt corect pentru a fi suprascrise.

Sunt sigur că sunt detalii pe care le-am omis, dar acesta este modul general în care funcționează.