El 5/12/20 a les 9:48, Narcis Garcia ha escrit:
El 5/12/20 a les 7:22, Àlex ha escrit:El 5/12/20 a les 6:59, Àlex ha escrit:El 4/12/20 a les 18:00, Narcis Garcia ha escrit:Tinc un ordinador amb unitat SSD i, quan executo aquesta instrucció: $ sudo fstrim -a -v Em diu: /boot: 766,7 MiB (803893248 bytes) trimmed on /dev/sda1 /: 243,1 GiB (261022449664 bytes) trimmed on /dev/mapper/sda2_crypt Algú sap quin és el problema i com resoldre'l ? Algú sap si hi ha programari per a fer anàlisi detallat d'aquest tema?Narcís, Crec que fstrim en general no augmenta gaire el rendiment del disc, però pot donar problemes si s'utilitza molt freqüentment i sobretot si s'utilitza sobre volums encriptats. Per exemple: https://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html Si vols millorar rendiment, passa de fstrim, posa la informació confidencial en una partició a banda i encripta només aquesta partició, no tota l'arrel / Salutacions Àlexhttps://www.spinics.net/lists/raid/msg40916.html https://wiki.debian.org/SSDOptimization#Mounting_SSD_filesystemsNo vull augmentar la velocitat de la unitat, sinó recuperar-la com era al principi. L'arrel està encriptada perquè les dades són confidencials. Allò què fa l'usuari és confidencial (i es revela a /tmp /var/tmp i altres ubicacions) juntament amb còpies temporals de documents que es poden obrir i eines que poden treballar a /opt , apart de què: Veure quines aplicacions són instal·lades dóna pistes del format dels documents que es treballen per tal d'escarbar en el desxifrat. I també la distinció entre dades i programari dóna pistes entre la informació important i la resta. Porto anys donant voltes a aquest tema (amb xifrat i sense) i no acabo d'esbrinar quin és el problema amb Linux o util-linux. Ara per ara, per a rehabilitar una unitat SSD no veig altra sortida que utilitzar blkdiscard per a formatejar-la tota de nou. Salut; Narcís.
Per parts:Un xifratge decent i ben implementat (i no em refereixo a la implementació del programari que s'usi per xifrar sinó a l'ús que se'n fa) d'un sistema de fitxers no permetrà "escarbar" en el contingut, doncs el xifratge inclou per definició totes les metadades, tant les incrustades en el propi fitxer com les que corresponen al propi sistema de fitxers (propietat, permisos, ctime, mtime i atime les més evidents). Si el xifratge que uses depèn de l'ofuscació de dades tan trivials com saber si està instal·lat LibreOffice, aquest xifratge no val per a res.
És més, el mer fet de fer servir fstrim ja dóna metadades sobre el sistema de fitxers encriptat que, d'altra forma, serien impossibles o costoses d'aconseguir: estadístiques d'ús del disc. Després d'un fstrim només cal comptar quina proporció de sectors estan marcats com a reutilitzables per tenir una aproximació prou fiable de quin és el resultat de du, i donat que aquesta llista pot ser molt més fàcil d'obtenir i que es pot anar comparant durant el temps, es podria arribar a deduir a més llarg termini quins sectors són els ocupats per programari (dades estàtiques) i quins per documents i treballs en ús actiu (dades dinàmiques), tot això sense desxifrar mai ni un míser bit.
Si, per altra banda, el que et preocupa és que s'usin vulnerabilitats per infiltrar-se al sistema i per això cal saber quins programes s'han d'intentar explotar, doncs aquí la clau és mantenir el sistema correctament actualitzat i instal·lant només de fonts de confiança (que, en el meu cas, és única i exclusivament el repositori de Debian). No cal ser molt espavilat per assumir que un sistema Linux d'escriptori tindrà, amb molta probabilitat, llibreries GTK (encara que usi KDE), un servidor CUPS en marxa, LibreOffice com a suite ofimàtica i les llibreries de ffmpeg i/o VLC per a multimèdia. Per no parlar de si s'envien a l'exterior documents creats i/o modificats en aquesta màquina, metadades dels quals poden donar indicis de què s'hi ha emprat.
Però és que, a més, per aquest tipus d'infiltracions, el xifratge de disc de la partició arrel és inútil, doncs només resulta efectiu mentre el propi sistema de fitxers està desmuntat. En el cas del sistema arrel, doncs, el xifratge només és efectiu mentre l'ordinador estigui apagat. Un cop engegat (i entrada la clau de desxifratge), adéu a tota la protecció que ofereix. Si una vulnerabilitat s'explota amb l'ordinador engegat (que, fins que jo sé, sol ser el cas en la majoria d'ocasions), ja ho tens...
Amb això no estic dient que el xifratge de disc no sigui útil, però que cal ser molt conscient de per què és útil i per a què no serveix, puix no hi res pitjor que una falsa sensació de seguretat que et faci abaixar la guàrdia. El xifratge és una peça important del complex trencaclosques per assegurar i blindar un sistema informàtic, però cal saber-la col·locar junt amb les altres peces. I l'ofuscació, per regla general, és la peça que sempre sobra.
Dita la qual cosa, si pel que entenc el fstrim no és efectiu a la partició arrel xifrada (via /dev/mapper, que honestament desconec si passa les ordres TRIM al dispositiu pare) però tampoc a la d'arrencada (que, com bé apuntes, està directament sobre un dispositiu físic de disc), m'inclino a pensar més aviat que el problema rau en la pròpia controladora del disc SSD que s'ho passa per l'Arc de Triomf. Això, o un bug a fstrim o al kernel per al dispositiu en qüestió que faci que no acabi rebent l'ordre correcta.
Si dius que et passa de fa temps, jo canviaria de proveïdor o de marca dels discs SSD. Perquè l'alternativa seria que fstrim no li funcionés a ningú, però el fet que ara mateix no hi hagi cap bug obert [1] al respecte em fa sospitar que no seria el cas.
[1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3Afstrim;package=util-linux