Când un container pare să „piardă” un fișier sau să afișeze două versiuni ale aceleiași structuri, problema nu este întotdeauna în aplicație. De multe ori, explicația se află mai jos, în modul în care OverlayFS construiește o singură vedere din mai multe straturi de filesystem.
OverlayFS este folosit frecvent în ecosistemul containerelor Linux pentru că permite combinarea unui strat de bază, de obicei read-only, cu un strat superior, writable. În limbajul Docker, documentația vorbește despre lowerdir, upperdir, merged și workdir. lowerdir conține datele venite din imagine, upperdir păstrează modificările containerului, iar merged este vederea finală pe care o vede procesul din container.
Această vedere este practică, dar poate deruta. Un fișier afișat în container nu este neapărat acolo unde pare. Poate veni din imagine, poate fi copiat în stratul writable sau poate fi mascat de o regulă internă a OverlayFS.
Ce face copy-up
Copy-up apare atunci când un fișier existent într-un strat inferior trebuie modificat. Pentru că stratul lower este, în mod normal, read-only, OverlayFS nu îl schimbă direct. Înainte de scriere, fișierul este copiat în upperdir, împreună cu metadatele relevante, iar modificarea se aplică pe copia din stratul superior.
De aici apar două efecte importante. Primul: prima scriere poate fi mai costisitoare decât pare, mai ales dacă fișierul este mare. Documentația Docker notează că OverlayFS lucrează la nivel de fișier, nu de bloc, deci operațiunea de copy-up poate copia întregul fișier. Al doilea: după copy-up, containerul vede versiunea din upperdir, chiar dacă în lowerdir există în continuare versiunea originală.
Pentru administratori, acest lucru explică situațiile în care un fișier „dublat” apare în analizele făcute din afara containerului: o versiune este în imagine, alta în stratul writable. În interiorul containerului, însă, regula este simplă: versiunea din upperdir o ascunde pe cea din lowerdir.
Whiteouts: ștergerea care nu șterge stratul de bază
Când un fișier este șters dintr-un container, OverlayFS nu poate elimina fișierul din imaginea de bază. În schimb, creează în stratul superior un marker numit whiteout. Documentația kernelului descrie whiteout-ul ca un dispozitiv caracter 0/0 sau ca un fișier de dimensiune zero marcat prin xattr-ul trusted.overlay.whiteout.
Rezultatul este contraintuitiv: fișierul încă există în lowerdir, dar nu mai este vizibil în vederea merged. Pentru container, fișierul este șters. Pentru cine inspectează straturile manual, el pare încă prezent. Asta poate da impresia că sistemul „minte” sau că există inconsistențe, deși OverlayFS doar respectă modelul union filesystem.
Directoare opace: când un director ascunde ce este sub el
Pentru directoare, OverlayFS folosește conceptul de opaque directory. Un director din upperdir poate fi marcat prin xattr-ul trusted.overlay.opaque cu valoarea y. Când se întâmplă asta, directorul corespunzător din lowerdir nu mai este combinat cu el. Este ignorat.
Această regulă explică multe cazuri în care un container pare că a „pierdut” conținutul unui director. Nu înseamnă obligatoriu că fișierele au dispărut din imagine sau din stratul inferior. Poate însemna că directorul superior a devenit opac, iar conținutul inferior nu mai intră în rezultatul final.
Kernelul menționează și cazul în care directoarele merge pot fi marcate cu trusted.overlay.opaque=x pentru optimizare, astfel încât sistemul să nu verifice inutil whiteout-uri pe toate intrările la readdir. Aceste detalii contează mai ales când se investighează diferențe între ce vede aplicația și ce vede un administrator în directoarele de stocare ale runtime-ului.
Xattrs: metadatele mici care schimbă imaginea mare
Extended attributes, sau xattrs, sunt esențiale pentru OverlayFS. Kernelul precizează că upper filesystem trebuie să suporte atribute extinse trusted. și/sau user., iar Docker atrage atenția și asupra cerințelor pentru filesystem-ul de bază, inclusiv suportul d_type pe XFS.
Dacă xattrs sunt pierdute prin backup, copiere necorespunzătoare sau migrare neatentă, interpretarea straturilor se poate schimba. Un whiteout poate să nu mai fie recunoscut. Un director opac poate deveni un director obișnuit. Rezultatul poate fi exact genul de comportament care sperie echipele: fișiere care reapar, directoare care par combinate greșit sau diferențe între mediul vechi și cel restaurat.
Ce verifici când apar diferențe
Într-o investigație defensivă, primul pas este să stabilești ce mount vede procesul. Fișierul /proc/pid/mountinfo, documentat în man-pages, arată informații despre mount-urile unui proces și poate ajuta la înțelegerea straturilor implicate. Apoi merită comparată vederea merged cu lowerdir și upperdir, fără a modifica manual directoarele gestionate de Docker sau de runtime. Docker avertizează explicit că fișierele din /var/lib/docker sunt administrate de Docker și nu trebuie manipulate direct.
OverlayFS nu este un bug atunci când ascunde, copiază sau maschează fișiere. Este mecanismul prin care containerele pot porni rapid din imagini read-only și pot păstra modificările separat. Pentru utilizatorii avansați de Linux, cheia este să nu trateze merged ca pe un filesystem clasic, ci ca pe rezultatul unei negocieri între straturi, whiteouts, directoare opace și xattrs.
