Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user.catalan > #6481 > unrolled thread

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

Back to article view | Back to linux.debian.user.catalan

Contents

  (deb-cat) Efecte acumulatiu de SSD, que no fa net Narcis Garcia <debianlists@actiu.net> - 2020-12-04 18:10 +0100
    Re: (deb-cat) Efecte acumulatiu de SSD, que no fa net Àlex <alex@probeta.net> - 2020-12-05 07:10 +0100
      Re: (deb-cat) Efecte acumulatiu de SSD, que no fa net Àlex <alex@probeta.net> - 2020-12-05 07:30 +0100
        Re: (deb-cat) Efecte acumulatiu de SSD, que no fa net Narcis Garcia <debianlists@actiu.net> - 2020-12-05 09:50 +0100
          Re: (deb-cat) Efecte acumulatiu de SSD, que no fa net Eloi <entfe001@gmail.com> - 2020-12-07 22:10 +0100
            Re: (deb-cat) Efecte acumulatiu de SSD, que no fa net Narcis Garcia <debianlists@actiu.net> - 2020-12-08 10:20 +0100

#6481 — (deb-cat) Efecte acumulatiu de SSD, que no fa net

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

I si ho torno a fer:
$ sudo fstrim -a -v
/boot: 0 B (0 bytes) trimmed on /dev/sda1
/: 0 B (0 bytes) trimmed on /dev/mapper/sda2_crypt

...amb la qual cosa sembla que ha fet efecte. PERÒ NO!
Si aturo i torno a iniciar l'ordinador, les xifres van igual per molt
que repeteixi l'operació.
El cas és que la unitat cada mes va més lenta, ara ja quasi com un disc
dur tradicional.

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?

Gràcies.

-- 
Narcis Garcia

__________
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.

[toc] | [next] | [standalone]

#6482

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

[toc] | [prev] | [next] | [standalone]

#6483

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

[toc] | [prev] | [next] | [standalone]

#6484

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.

[toc] | [prev] | [next] | [standalone]

#6486

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 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

[toc] | [prev] | [next] | [standalone]

#6487

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 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
> 

Està molt bé debatre sobre un altre assumpte (eficàcia i estratègies de
xifrat), però de diverses unitats SSD (amb i sense xifrat) no
aconsegueixo que conservin el rendiment que se li espera a aquesta
tecnologia, degut a què els blocs alliberats no es descarten.
També m'ha passat en màquines virtuals (KVM) amb SSD virtual.

La controladora SATA no la puc canviar sense canviar l'ordinador, i per
a canviar el SSD n'hauria de comprar un altre, i sense tampoc no saber
si hi haurà més sort.
En aquest ordinador concret el problema l'arrossego amb els nuclis Linux
4.19 (buster) 5.6 (buster-backports) 5.7 (buster-backports) i 5.8
(buster-backports)
i en altres ordinadors no et sabria dir (és possible que deb-stretch i
ub-bionic segons el cas)

La dificultat a la què m'enfronto és la manca d'eines per a analitzar el
problema. Com veig si la unitat SSD ha rebut l'ordre de descartar un
bloc? Com veig si un bloc «es considera» descartat o realment ho està?
Com veig la situació dels blocs a mitges (que estan utilitzats en part)?

Narcís.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user.catalan

csiph-web