Re: (deb-cat) Efecte acumulatiu de SSD, que no fa net

2020-12-08 Conversa Narcis Garcia
El 7/12/20 a les 22:05, Eloi ha escrit:
> 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

     Àlex

>>> https://www.spinics.net/lists/raid/msg40916.html
>>>
>>> https://wiki.debian.org/SSDOptimization#Mounting_SSD_filesystems
>>>
>> No 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 

fsck amb raid1 + lvm

2020-12-08 Conversa Lluís Gras
Bones,

Aquest matí m'he trobat el servidoret de casa "gripat", ahir se'n va anar
el corrent i aparentment quan va tornar a arrencar va tirar de journal i
corregir errors en inodes i aquests coses màgiques que fa el fsck.

El cas és que he reiniciat l'equip i m'he trobat el prompt (initramfs), he
fet un fsck -p /dev/mapper/gv00-arrel i aparentment s'han corregit els
errors, torno a engegar i ara el sistema arrenca però en mode ro, més fsck
més comprovacions amb smartctl (sense errors, 18076 hores de funcionament)
i més reinicis fins que quan ja en començava a estar fins al capdamunt i
després de l'enèssim fsck + reinici, la maquineta ha arrencat sense donar
errors.

I la pregunta ??? ... doncs la pregunta és si algú s'hi ha trobat i perquè
el fsck em diu que ja ha corregit tots els errors i quan torna a
arrencar en torna a trobar en inodes diferents, etc ...