DOMANDA SSD guasto ma ancora leggibile ...come mai?

[pseudonimo]

Salve.
Nel mio PC desktop usavo un semplice SSD mSATA con NAND TLC che però si è rotto durante un blackout elettrico.
Come software stavo usando Linux Debian installato col classico file system ext4.

Essendo un principiante che non vuole perdere tempo col terminale, ho semplicemente acquistato un nuovo SSD più duraturo con NAND MLC.
Fortunatamente avevo fatto il backup di tutti i dati e della configurazione, quindi reinstallare tutto è stato relativamente facile.

Però mi è rimasto il dubbio che il primo SSD non fosse completamente rotto e forse c'era stato solo un problema di corruzione di metadati del file system. Quindi l'ho collegato come memoria esterna e con mia sorpresa ho constatato che è possibile accedere ai dati e leggere i file tranquillamente.

Tuttavia, una volta smontato il drive, le partizioni non si possono formattare perché GParted restituisce un errore mentre se provo a eliminarle completamente mi dice che l'operazione è riuscita (spazio non allocato) quando invece non ha fatto alcuna modifica, tutti i dati riappaiono e tornano sempre lì, impossibile eliminarli!

In pratica è come se i file fossero ibernati e puoi solamente leggerli. Perché?
A qualcuno è capitato un guasto simile?
Grazie.

 

[giulore]

Dovresti dirci cosa succede esattamente, guasto perchè ?
Cosa succede quando cerchi di avviarlo ?
Potrebbe essere solo compromesso il filesystem che potrebbe essere recuperato banalmente con un chkdsk o sfc o dism .

.

 

[r3dl4nce]

Salve.
Nel mio PC desktop usavo un semplice SSD mSATA con NAND TLC che però si è rotto durante un blackout elettrico.

mSATA? Ma intendi NVME?

Essendo un principiante che non vuole perdere tempo col terminale, ho semplicemente acquistato un nuovo SSD più duraturo con NAND MLC.

Ma che marca e modello è? Non è un M2 SATA vero?

Però mi è rimasto il dubbio che il primo SSD non fosse completamente rotto e forse c'era stato solo un problema di corruzione di metadati del file system. Quindi l'ho collegato come memoria esterna e con mia sorpresa ho constatato che è possibile accedere ai dati e leggere i file tranquillamente.

Quindi non è danneggiato

Tuttavia, una volta smontato il drive, le partizioni non si possono formattare perché GParted restituisce un errore mentre se provo a eliminarle completamente mi dice che l'operazione è riuscita (spazio non allocato) quando invece non ha fatto alcuna modifica, tutti i dati riappaiono e tornano sempre lì, impossibile eliminarli!

Intanto, se hai file importanti, se riesci a leggerli, copia tutto e via. E controlla anche che si aprano, se hai foto vedi se si vedono, idem video, prova a aprire i documenti, ecc
Fatto ciò, prova un gdisk /dev/sdX e poi il comando o e poi w

Potrebbe essere solo compromesso il filesystem che potrebbe essere recuperato banalmente con un chkdsk o sfc o dism .

Non è mica in NTFS, è in ext4...

 

[pseudonimo]

@giulore:
Appunto ...guasto perché?
È proprio quello che vorrei capire.
Quando provavo ad avviare, appariva un messaggio (che non ho memorizzato) secondo il quale il file system non poteva essere riparato e recuperato. In pratica era un danno apparentemente irreversibile. Ma il motivo esatto non lo diceva.

@r3dl4nce:
Stiamo parlando di un mSATA SSD in dotazione col miniPC. Il termine "mSATA" è scritto sia sulle istruzioni sia sullo stesso drive. Quindi nessun errore.
Scusa ma il nuovo SSD funziona perfettamente quindi non capisco perché dovremmo parlarne. Comunque grazie mille per le informazioni.
In realtà il mio obiettivo non è recuperare i dati o far risuscitare il vecchio drive a tutti i costi. Sarebbe sufficiente capire come mai le partizioni non possono essere eliminate. E magari optare per un file system diverso da ext4 per evitare che in futuro possa capitare di nuovo...

Non so altro. Spiacente.
Se le informazioni sono insufficienti per avanzare una qualsiasi ipotesi sul tipo di guasto, non preoccupatevi e non scervellatevi, ignorate questa discussione o chiedete di chiuderla. Non è di importanza vitale

 

[r3dl4nce]

Stiamo parlando di un mSATA SSD in dotazione col miniPC. Il termine "mSATA" è scritto sia sulle istruzioni sia sullo stesso drive. Quindi nessun errore.

Ok, allora si tratta di roba vecchia e/o fascia infima dato che ormai gli msata non sono quasi più in produzione

Scusa ma il nuovo SSD funziona perfettamente quindi non capisco perché dovremmo parlarne.

Ti lamenti di un SSD probabilmente di fascia bassa che ha avuto problemi, lo cambi senza neppure dare indicazioni relative a con cosa lo hai sostituito, forse prima sarebbe stato bene chiedere informazioni., Parli di celle ma mica sono le uniche a dare problemi, potrebbe essere un problema con il controller, con il firmware ecc.
Fatto sta che se si parla di mSATA ormai è tutta roba cinesata di fascia bassa quindi in effetti uno vale l'altro, non ci salverei però nessun dato importante dato che non li ritengo affidabili in alcun modo.

In realtà il mio obiettivo non è recuperare i dati o far risuscitare il vecchio drive a tutti i costi. Sarebbe sufficiente capire come mai le partizioni non possono essere eliminate. E magari optare per un file system diverso da ext4 per evitare che in futuro possa capitare di nuovo...

Potresti usare btrfs, ma se il guasto è hardware non cambia nulla.

Hai fatto la prova a azzerare il disco e creare una nuova tabella GPT come ti ho indicato con i comandi da gdisk?

 

[giulore]

mSATA? Ma intendi NVME?


Ma che marca e modello è? Non è un M2 SATA vero?


Quindi non è danneggiato



Intanto, se hai file importanti, se riesci a leggerli, copia tutto e via. E controlla anche che si aprano, se hai foto vedi se si vedono, idem video, prova a aprire i documenti, ecc
Fatto ciò, prova un gdisk /dev/sdX e poi il comando o e poi w





Non è mica in NTFS, è in ext4...

Si, non so perchè avevo capito che aveva 2 sistemi e il secondo fosse linux .


.

 

[pseudonimo]

Grazie r3dl4nce, ora capisco la tua domanda. No, il nuovo SSD non è un altro mSATA!
Per fortuna c'era anche un'interfaccia SATA e quindi ho preso un SSD SATA da 2,5 pollici, di quelli che si usano nei notebook. Inoltre ha la NAND MLC di durata superiore. Non mi piace nominare marchi e modelli, ma certamente non è di fascia bassa.
Probabilmente ha un controller che gestisce l'emergenza dell'improvvisa assenza elettrica. Quindi può darsi che il problema sia stato risolto definitivamente.

Comunque avevo letto delle incedibili funzionalità di Btrfs le quali danno maggiore sicurezza in caso di interruzione dell'alimentazione elettrica, ma questo comporta continue letture e scritture che accorciano la vita di un SSD. E una volta rotto è rotto a prescindere dal file system scelto. Forse nel mio caso sarebbe meglio una via di mezzo come Xfs. Boh!

Dovrò informarmi sui possibili danni dei file system o di tipo hardware in caso di blackout, evento ormai raro, visto che oggi tutti preferiscono usare dispositivi mobili con batteria non estraibile.
E se poi il danno fosse hardware, come giustamente dicevi tu, sarebbe inutile pensare che il software possa risolvere ogni problema.

 

[r3dl4nce]

Per fortuna c'era anche un'interfaccia SATA e quindi ho preso un SSD SATA da 2,5 pollici, di quelli che si usano nei notebook.

Perfetto, molto meglio un SSD di un mSATA. Gli SSD sono tutti da 2.5"

Inoltre ha la NAND MLC di durata superiore. Non mi piace nominare marchi e modelli, ma certamente non è di fascia bassa.

Se non specifichi marca e modello, non posso farti sapere se hai fatto un buon acquisto o no. Fai come vuoi comunque.

Probabilmente ha un controller che gestisce l'emergenza dell'improvvisa assenza elettrica. Quindi può darsi che il problema sia stato risolto definitivamente.

A meno di controller da server con BBU, gli SSD consumer non hanno particolare protezione da assenza elettricità. Ma questo vuol dire poco, dato che penso che il tuo problema del SSD precedente sia principalmente dovuto a problemi di file system
Sarebbe interessante vedere i dati SMART di entrambi con smartctl, ti potrei dare indicazioni più precise, invece così stiamo parlando senz adati effettivi alla mano e sinceramente non capisco cos atu abbia "da nascondere"

Comunque avevo letto delle incedibili funzionalità di Btrfs le quali danno maggiore sicurezza in caso di interruzione dell'alimentazione elettrica,

Falso

ma questo comporta continue letture e scritture che accorciano la vita di un SSD.

Hai grande confusione. Un SSD attuale non ha problemi con file system CoW

E una volta rotto è rotto a prescindere dal file system scelto. Forse nel mio caso sarebbe meglio una via di mezzo come Xfs. Boh!

No, basta avere dei validi backup su unità esterna.

Dovrò informarmi sui possibili danni dei file system o di tipo hardware in caso di blackout, evento ormai raro, visto che oggi tutti preferiscono usare dispositivi mobili con batteria non estraibile.
E se poi il danno fosse hardware, come giustamente dicevi tu, sarebbe inutile pensare che il software possa risolvere ogni problema.

E ripeto, postare i dati SMART con smartctl -a sarebbe interessante. Oltre ai modelli degli storage.

Poi vabbè fai te, la disponibilità c'è, se però non dai le indicazioni richieste, non è possibile darti aiuto e / o indicazioni specifiche

 

[Liupen]

Salve.
Nel mio PC desktop usavo un semplice SSD mSATA con NAND TLC che però si è rotto durante un blackout elettrico.
Come software stavo usando Linux Debian installato col classico file system ext4.

Però mi è rimasto il dubbio che il primo SSD non fosse completamente rotto e forse c'era stato solo un problema di corruzione di metadati del file system. Quindi l'ho collegato come memoria esterna e con mia sorpresa ho constatato che è possibile accedere ai dati e leggere i file tranquillamente.

Tuttavia, una volta smontato il drive, le partizioni non si possono formattare perché GParted restituisce un errore mentre se provo a eliminarle completamente mi dice che l'operazione è riuscita (spazio non allocato) quando invece non ha fatto alcuna modifica, tutti i dati riappaiono e tornano sempre lì, impossibile eliminarli!

In pratica è come se i file fossero ibernati e puoi solamente leggerli. Perché?

Quando provavo ad avviare, appariva un messaggio (che non ho memorizzato) secondo il quale il file system non poteva essere riparato e recuperato. In pratica era un danno apparentemente irreversibile. Ma il motivo esatto non lo diceva.

E magari optare per un file system diverso da ext4 per evitare che in futuro possa capitare di nuovo...

Grazie r3dl4nce, ora capisco la tua domanda. No, il nuovo SSD non è un altro mSATA!
Per fortuna c'era anche un'interfaccia SATA e quindi ho preso un SSD SATA da 2,5 pollici, di quelli che si usano nei notebook. Inoltre ha la NAND MLC di durata superiore. Non mi piace nominare marchi e modelli, ma certamente non è di fascia bassa.
Probabilmente ha un controller che gestisce l'emergenza dell'improvvisa assenza elettrica. Quindi può darsi che il problema sia stato risolto definitivamente.

Comunque avevo letto delle incedibili funzionalità di Btrfs le quali danno maggiore sicurezza in caso di interruzione dell'alimentazione elettrica, ma questo comporta continue letture e scritture che accorciano la vita di un SSD. E una volta rotto è rotto a prescindere dal file system scelto. Forse nel mio caso sarebbe meglio una via di mezzo come Xfs. Boh!

Ciao.
Lo stato dell'ssd è probabilmente quello definito in gergo di "sola lettura".

Innanzitutto, cosa causa lo stato di sola lettura "Read Only"?
Un imput delle nand flash al controller se avviene per esaurimento delle celle "di scorta" o il controller stesso se c'è una instabilità accidentale del firmware o un malware volontario.

Cosa comporta la modalità di sola lettura per un ssd o per una pendrive usb?
Come dici il congelamento dei dati sul dispositivo e l'impossibilità di scriverci sopra (e cancellarci ovviamente).
Se l'ssd contiene un OS, visto che funziona facendo delle micro-scritture (oltre alle letture), ci si troverà di fronte a errori fatali..
Meglio se l'ssd in sola lettura è un ssd di dati, si potrà continuare ad utilizzarlo fino a quando si cercherà di scriverci o cancellarci dati.

Penso che quel blackout abbia creato questa condizione, ma può anche essere successo che l'ssd sia stato usato molto e si sia "consumato".

Qui ad esempio una videata di Crystaldiskinfo di un ssd in sola lettura perchè consumato

Spoiler

Mi ricordo che ad un certo punto Intel fece del read only un punto pro per l'endurance

Intel Clarifies 600p SSD Endurance Limitations, But TBW Ratings Can Be Misleading (Updated)

Intel clarified the process for recovering data after its SSDs enter into the locked state, but we also want to clear up some common misconceptions about endurance ratings, which SSD vendors spec with the somewhat misleading "TBW" measurement.

www.tomshardware.com

Ma un senso c'è l'ha in effetti.
C'è chi una decina di anni fà ha torturato a morte degli ssd per vedere come andava a finire...

The SSD Endurance Experiment: They're all dead

techreport.com

L'ssd Intel, appunto ha dimostrato di andare in read only come "precauzione" al blocco ed alla perdita di dati.

Comunque, direi che se constati che si tratta di questo, ed è stato accidentale (perchè vedi dallo smart che hai fatto poche scritture), allora direi che sei stato un po sfi.....o con questo ssd e che un MLC non ti para dalla sola lettura (ma sicuramente in condizioni normali ti dura di più).

Il file system Btrfs effettivamente porta dei miglioramenti nella durata degli ssd (giusto per l'uso di CoW - Copy-on-Write riduce il numero totale di scritture che il controller deve gestire, migliorando indirettamente l'efficienza di queste tecniche ) e l'uso di snapshot sono un grado di sicurezza migliore che NTFS non possiede (e come scrive r3dl4nce il peso di queste è insignificante nella visione generale dei centinaia di TB che gli attuali ssd sopportano per i tagli grandi che abbiamo ora).

 

[pseudonimo]

Grazie Liupen, tutto molto interessante.

Anche senza dati SMART, posso affermare con ragionevole certezza che la causa è stata accidentale perché l'SSD rotto non poteva essere "consumato" sebbene fosse di piccola taglia (128 GB). Non maneggio file audio o video, quindi un SSD più grande sarebbe inutile.
Non poteva essere consumato perché si è rotto dopo appena un paio d'anni di utilizzo desktop quotidiano, mentre il notebook che in passato ho utilizzato allo stesso modo per più di 4 anni, ha un SSD Intel anch'esso da 128 GB che non è mai andato in protezione con modalità sola lettura. Funziona ancora e lo uso addirittura per backup.

Per quanto riguarda il Btrfs, avete citato il copy-on-write, okay ma entra in scena solamente quando una risorsa viene copiata. Mi chiedo quanto possa influire globalmente sulla scrittura dei dati.
Anche tralasciando il journaling intensivo e gli snapshot, il checksum che Btrfs fa per verificare l'integrità dei file (anche in sola lettura) non prevede la scrittura e l'archiviazione del checksum di confronto? E lo fa continuamente! Tutto ciò non invecchia precocemente un SSD?

 

[r3dl4nce]

Puoi postare i dati SMART del vecchio mSATA e del nuovo ssd?

 

[pseudonimo]

Scusa r3dl4nce ma non ho proprio voglia di aprire per l'ennesima volta il miniPC per fare una verifica su un SSD mSATA guasto a causa di una interruzione elettrica.

Gsmartcontrol dice che il nuovo SSD è in salute, come ovvio che sia.

Smartctl Version 7.3 2022-02-28 r5338
Overall Health Self-Assessment Test PASSED

Tuttavia in futuro farò un monitoraggio regolare.

 

[Liupen]

Per quanto riguarda il Btrfs, avete citato il copy-on-write, okay ma entra in scena solamente quando una risorsa viene copiata. Mi chiedo quanto possa influire globalmente sulla scrittura dei dati.
Anche tralasciando il journaling intensivo e gli snapshot, il checksum che Btrfs fa per verificare l'integrità dei file (anche in sola lettura) non prevede la scrittura e l'archiviazione del checksum di confronto? E lo fa continuamente! Tutto ciò non invecchia precocemente un SSD?

Nessun file system è perfetto, neanche Btrfs.

Certamente è un compromesso anche questa riduzione di scritture in ottica ssd: da una parte la funzione integrata di copy-on-write viene gestita mediante una virtualizzazione tra dati OS e struttura fisica, quindi in effetti tiene una ulteriore mappatura virtuale che NTFS non ha e che ovviamente pesa sull'ssd (microscritture), dall'altra quella stessa funzione consente di, in caso di modifica di un dato qualsiasi (operazione di scrittura su ssd quindi), di riscrivere il dato, renderlo valido, ma conservare il vecchio dato (reso in sola lettura) ovvero gli snapshot dei dati.

Ora, perchè questo "metodo" o funzione, che, è evidente, scrive di più, dovrebbe portare benefici ad un ssd?

Purtroppo non ho trovato neanche in rete delle spiegazioni chiare in merito e le ipotizzo in base alle mie conoscenze sugli ssd e alla struttura di questo file system per Linux https://it.wikipedia.org/wiki/Btrfs

Un ssd per struttura fisica scrive su singole pagine ma deve cancellare a blocchi (cioè prendendo un set notevole di pagine scritte e che hanno frammenti di dati appartenente a file diversi.
In tutto questo il TRIM->Garbage Collection (GC) e il Wear leveling (WL), cercano di mantenere l'uso delle celle, quindi dei blocchi, uniformi.
In un file system tradizionale, ogni volta che un file viene modificato, il sistema (punto di vista dell'host) riscrive i dati sullo stesso blocco di memoria. Questa operazione implica un ciclo di cancellazione e scrittura, che contribuisce all'usura delle celle NAND degli SSD.
Infatti, l'operazione descritta prima, si traduce fisicamente per l'ssd nello spostamento di dati validi (GC), nella riscrittura del dato modificato nella sola porzione dei blocchi annullati e consecutivamente nella cancellazione di questi blocchi annullati. L'effetto è una frammentazione dei dati ovvero un aumento della WA. Poiché le celle di memoria degli SSD hanno un numero limitato di cicli di scrittura (Write Endurance), riscrivere più volte sui blocchi riduce la loro durata.
Con CoW, quando vengono apportate modifiche a un file, il file system scrive i nuovi dati in blocchi di memoria liberi, lasciando i dati originali intatti. Solo dopo che la nuova scrittura è completata e verificata, i metadati vengono aggiornati per puntare ai nuovi blocchi. Questo riduce l'usura delle celle, poiché il blocco originale non viene modificato fino a quando non è necessario.
Questa volta, vedendolo dal punto di vista fisico dell'ssd, quando viene dato l'input di scrittura, è una scrittura ex novo di blocchi senza andare ad innescare il GC. Solo DOPO i vecchi blocchi vengono annullati ed il controller procede alla cancellazione.
Anche con il meccanismo di CoW, il controller dell'SSD deve effettivamente riscrivere blocchi di dati, che non possono essere semplicemente modificati "in-place". Tuttavia, il vantaggio di CoW per un SSD esiste, anche se in modo indiretto, e si basa su come gestisce le scritture e sull'interazione con il WL. CoW aiuta a ridurre la frammentazione interna che si verificherebbe altrimenti con sovrascritture continue. In altre parole, CoW gestisce in modo più efficiente lo spazio libero dell'SSD, distribuendo le scritture, riducendo la WA quindi l'usura generale.

Di contro, il checksumming sui dati e metadati, rema contro dato che richiede operazioni di scrittura aggiuntive.
Però c'è da dire che i dati di checksum non sono una replica dei dati ma sono un insieme di indirizzi mentre l'operazione di controllo CRC è di sola lettura.

Quindi, anche se Btrfs aggiunge un overhead in termini di scritture, il suo design complessivo, che include CoW e altre ottimizzazioni, bilancia l'usura dell'SSD, evitando un deterioramento accelerato in molti scenari.

 

[r3dl4nce]

Scusa r3dl4nce ma non ho proprio voglia di aprire per l'ennesima volta il miniPC per fare una verifica su un SSD mSATA guasto a causa di una interruzione elettrica.

Io invece non credo affatto che sia guasto, soprattutto per un'interruzione elettrica.
Inoltre hai scritto di aver preso un adattatore per leggerlo come memoria esterna, per questo volevo verificare lo stato SMART, dato che se hai un problema sulla scheda madre, allora si potrebbe nuovamente presentare anche sul nuovo SSD

Gsmartcontrol dice che il nuovo SSD è in salute, come ovvio che sia.

Tuttavia in futuro farò un monitoraggio regolare.

Non hai postato quello che ti ho chiesto e non specifichi che SSD hai preso, in tal caso posso solo supporre che tu abbia preso una schifezza cinesata e non vuoi che ti venga detto, per cui si guasterà ben presto e darai nuovamente colpa a fantomatiche "interruzioni elettriche" quando invece non sarà così

I dati sono tuoi, il pc è tuo, contento te.


Passiamo alla questione file system ext4. Il mio dubbio è che sul vecchio mSATA, in seguito allo spengimento non regolare, il file system ext4 sia stato markato come non clean e venga montato in read only mode, infatti riesci a leggere i file. Nulla di strano, ci può stare, il problema generalmente in questi casi non è hardware ma appunto software del file system, se si rovinano certi settori (fortunatamente generalmente replicati) che contengono certi metadati necessari a identificare e fare il mount regolare del file system, questo viene segnato come danneggiato e richiede un fsck per essere sistemato, a quel punto se gli errori vengono risolti, il file system torna pulito e utilzzabile anche in RW. I dati smart del vecchio mSATA sarebbero interessanti da vedere, perché se non ci sono anomalie particolari sul disco, errori crc, eventi di riallocazione, errori DMA, ecc allora è quasi certo che non ci siano problemi hardware e anche il PC non dovrebbe avere problematiche hardware (generalmente problematiche relative all'alimentazione). Se i dati smart avessero mostrato errori DMA, si potrebbe pensare a problemi dello slot mSATA ma anche a problemi di alimentazione. Ma senza vedere i dati samrt, non si può sapere.

Relativamente a BTRFS ti ha spiegato bene @Liupen - in realtà chi cononosce bene il mondo Linux e ne segue vicissitudini da anni, sa di BTRFS e di come fosse nato per essere un'evoluzione con nuove tecnologie dei file system storici quali ext3/4 e xfs o addirittura il vecchio reiserfs. I vantaggi di BTRFS e dei file system CoW è legato alla possibilità di avere snapshot di facile creazione e utilizzo gestiti direttamente dal file system, oltre a integrare già tutti i sistemi di gestione multi disco (raid di vario tipo, nonostante ancora ci siano problemi per i raid con parità). Sugli SSD, soprattutto sugli SSD attuali che hanno comunque endurance più che elevate, un file system CoW non presenta svantaggi di alcun tipo, anzi gestisce bene il sistema di memorizzazione a celle degli SSD visto che porta a meno riscritture di celle visto che il CoW porta a scrivere dat in nuovi settori ogni volta che ci sono scritture. L'importante è SEMPRE con ogni SSD / NVME di non farlo arrivare a un'occupazione troppo elevata, io consiglio di non superare mai l'80% della capacità, così che ci sono sempre celle libere per evitare troppe scritture sempre sulle stesse.

Attenzione che tutto questo non ha nulla a che fare con la protezione da interruzione elettrica improvvisa (anzi, è proprio in quei casi che c'è il rischio del "bug" sui raid btrfs con parità), ma si suppone che generalmente ci sia un UPS su un PC importante o nel caso di un portatile c'è la batteria interna, se va via la corrente c'è tempo per spengere correttamente

 

[pseudonimo]

r3dl4nce nei tuoi post ho letto molte inesattezze, ma non mi va di aprire una discussione infinita su queste sciocchezze.
Qualora tu avessi avuto una ipotesi precisa sul motivo per il quale tutte le partizioni non possono essere eliminate con SSD smontato, allora avresti dovuto chiedere quali dati esatti ti servono e per quale finalità.

Invece hai chiesto una montagna di dati a vanvera, senza fornire alcuna ipotesi precisa, quindi posso solo supporre che non ci hai capito molto e che i dati ti servono nella speranza di farti venire qualche idea, o per mera curiosità personale.