2018-11-22, 12:18
  #1
Jag har kollat runt lite på nätet, och jag kan inte hitta nånstans där det verifieras att man kan återställa raderade filer från en SSD-disk om man har filsystemet ext4 och kört TRIM.
Är det fel, eller är filerna oåterkalleligt förlorade?
__________________
Senast redigerad av Vladulven 2018-11-22 kl. 12:41.
Citera
2018-11-22, 12:56
  #2
Medlem
StarkSomSatans avatar
Citat:
Ursprungligen postat av Vladulven
Jag har kollat runt lite på nätet, och jag kan inte hitta nånstans där det verifieras att man kan återställa raderade filer från en SSD-disk om man har filsystemet ext4 och kört TRIM.
Är det fel, eller är filerna oåterkalleligt förlorade?

Jag är osäker, SSD och mekaniska hårddiskar är väldigt annorlunda. Det är lite svårt att avgöra vad som händer med data på en SSD. Varför frågar du? Är det så att du bara är nyfiken, eller finns det data som du vill återställa? Om det är det senare alternativet så bör du stänga av datorn och absolut inte använda den och rådfråga en professionell tekniker inom området. Alternativt så kan du läsa igenom den här artikeln.
Citera
2018-11-22, 13:44
  #3
Citat:
Ursprungligen postat av StarkSomSatan
Varför frågar du? ---------- Alternativt så kan du läsa igenom den här artikeln.

Jag är mest intresserad. Artikeln verkar endast handla om HDD.
Citera
2018-11-22, 15:30
  #4
Medlem
Citat:
Ursprungligen postat av Vladulven
Jag har kollat runt lite på nätet, och jag kan inte hitta nånstans där det verifieras att man kan återställa raderade filer från en SSD-disk om man har filsystemet ext4 och kört TRIM.
Är det fel, eller är filerna oåterkalleligt förlorade?

Kort svar: Ja, i praktiken torde de vara oåterkallerligt förlorade.

Långt svar: TRIM gör att sektorerna som innehöll de raderade filerna kommer att markeras som tomma av SSD:n, men den fysiska raderingen av sektorernas innehåll sker typiskt i bakgrunden och med en viss fördröjning. Fysisk radering är långsam, så om man är snabb med att slå av datorn/SSD:n skulle det därför kunna finnas ett tidsfönster där det fortfarande går att rädda en del data. Men även om datasektorerna ännu inte är fysiskt raderade, finns det inget standardiserat sätt att komma åt innehållet i dem - när man på normalt sätt läser en TRIM:ad sektor kommer den troligen att leverera nollor eller skräpdata snarare än innehållet i den fysiska sektorn, som inte längre torde vara associerad med den logiska sektorn. Man skulle behöva läsa flashminnet "rått" med hjälp av specialhårdvara/-instruktioner och djup kunskap om hur SSD:n fungerar internt, och troligen ändå ha stora problem att koppla ihop räddade datasektorer med vilka filer de kommer ifrån.
__________________
Senast redigerad av vgebler 2018-11-22 kl. 15:38.
Citera
2018-11-22, 16:15
  #5
Citat:
Ursprungligen postat av vgebler
Kort svar: Ja, i praktiken torde de vara oåterkallerligt förlorade.

Långt svar: TRIM gör att sektorerna som innehöll de raderade filerna kommer att markeras som tomma av SSD:n, men den fysiska raderingen av sektorernas innehåll sker typiskt i bakgrunden och med en viss fördröjning. Fysisk radering är långsam, så om man är snabb med att slå av datorn/SSD:n skulle det därför kunna finnas ett tidsfönster där det fortfarande går att rädda en del data. Men även om datasektorerna ännu inte är fysiskt raderade, finns det inget standardiserat sätt att komma åt innehållet i dem - när man på normalt sätt läser en TRIM:ad sektor kommer den troligen att leverera nollor eller skräpdata snarare än innehållet i den fysiska sektorn, som inte längre torde vara associerad med den logiska sektorn. Man skulle behöva läsa flashminnet "rått" med hjälp av specialhårdvara/-instruktioner och djup kunskap om hur SSD:n fungerar internt, och troligen ändå ha stora problem att koppla ihop räddade datasektorer med vilka filer de kommer ifrån.

Tack för ett bra svar.
Citera
2018-11-22, 22:34
  #6
Medlem
Citat:
Ursprungligen postat av vgebler
Kort svar: Ja, i praktiken torde de vara oåterkallerligt förlorade.

Långt svar: TRIM gör att sektorerna som innehöll de raderade filerna kommer att markeras som tomma av SSD:n, men den fysiska raderingen av sektorernas innehåll sker typiskt i bakgrunden och med en viss fördröjning. Fysisk radering är långsam, så om man är snabb med att slå av datorn/SSD:n skulle det därför kunna finnas ett tidsfönster där det fortfarande går att rädda en del data. Men även om datasektorerna ännu inte är fysiskt raderade, finns det inget standardiserat sätt att komma åt innehållet i dem - när man på normalt sätt läser en TRIM:ad sektor kommer den troligen att leverera nollor eller skräpdata snarare än innehållet i den fysiska sektorn, som inte längre torde vara associerad med den logiska sektorn. Man skulle behöva läsa flashminnet "rått" med hjälp av specialhårdvara/-instruktioner och djup kunskap om hur SSD:n fungerar internt, och troligen ändå ha stora problem att koppla ihop räddade datasektorer med vilka filer de kommer ifrån.
Var står det att frigjorda block raderas i bakgrunden? Minnescellerna tål bara ett begränsat antal skrivningar och skulle frigjorda block nollas innan de återanvändes för ny skrivning, så skulle livslängden halveras till ingen nytta. Det jag hört är att frigjorda block flyttas till poolen av lediga block utan att nollas, allt annat vore ekonomiskt vansinne. Försöker man sedan läsa ett logiska block efter att det fysiska blocket frigjorts, så kommer kontrollern att returnera nollor så att det ser ut som att det fysiska blocket fanns kvar.

Det stämmer ju att man inte kommer åt att läsa frigjorda block med vanliga SATA-kommandon. Men det utesluter inte att man skulle kunna komma åt dem med tillverkarspecifik programvara. Eller att man löder dit en annan kontroller om man har expertkunskap. Det är därför man behöver använda secure erase för att vara säker på att man verkligen raderar innehållet innan man slänger en gammal SSD på tippen.
Citera
2018-11-23, 18:27
  #7
Medlem
Citat:
Ursprungligen postat av WbZV
Var står det att frigjorda block raderas i bakgrunden? Minnescellerna tål bara ett begränsat antal skrivningar och skulle frigjorda block nollas innan de återanvändes för ny skrivning, så skulle livslängden halveras till ingen nytta. Det jag hört är att frigjorda block flyttas till poolen av lediga block utan att nollas, allt annat vore ekonomiskt vansinne.

Programmerade flashsektorer måste raderas innan det går att skriva till dem igen. Så fungerar allt flashminne. Man kan göra denna radering i samband med skrivning, men det är smartare att göra det i förväg och i bakgrunden när inget annat behöver göras, eftersom det då går snabbare när man väl behöver skriva. Det är inget slöseri, eftersom man i båda fallet raderar sektorn exakt en gång - det är bara fråga om när man gör det.

Det här är allmänbildning inom mitt område (civilingenjör datateknik som jobbat mycket med flashbaserade inbyggda system) men om du vill ha något att läsa är det väl bara att leta upp valfritt datablad.

EDIT: Att kalla det "nollning" är f.ö. lite missvisande eftersom konventionen brukar vara sådan att raderade flashsektorer presenteras som enbart ettor. När man sedan skriver till sektorn sker det genom att nolla de celler som ska innehålla nollor. Att omvandla en nolla till en etta kräver däremot att hela sektorn raderas, och eftersom skrivningar normalt innebär att detta behövs, kan man lite förenklat uttrycka det som att en skriven sektor måste raderas innan den kan skrivas igen. På NAND-flash finns dessutom komplikationen att radering sker på blocknivå medan skrivning sker på sidnivå, där varje block innehåller multipla sidor. För att slita på NAND-flash så lite som möjligt är det därför bäst att vänta med radering av ett block tills alla dess sidor är skrivna. Hur som helst behöver kontrollern hålla reda på vilka block som är raderade och inte, och när den vet att en sida ligger på ett raderat block kan den ju presentera detta som "enbart nollor" för datorn även om det ser annorlunda ut rent fysiskt.
__________________
Senast redigerad av vgebler 2018-11-23 kl. 18:51.
Citera
2018-11-23, 19:29
  #8
Medlem
Citat:
Ursprungligen postat av vgebler
Programmerade flashsektorer måste raderas innan det går att skriva till dem igen. Så fungerar allt flashminne. Man kan göra denna radering i samband med skrivning, men det är smartare att göra det i förväg och i bakgrunden när inget annat behöver göras, eftersom det då går snabbare när man väl behöver skriva. Det är inget slöseri, eftersom man i båda fallet raderar sektorn exakt en gång - det är bara fråga om när man gör det.

Det här är allmänbildning inom mitt område (civilingenjör datateknik som jobbat mycket med flashbaserade inbyggda system) men om du vill ha något att läsa är det väl bara att leta upp valfritt datablad.

EDIT: Att kalla det "nollning" är f.ö. lite missvisande eftersom konventionen brukar vara sådan att raderade flashsektorer presenteras som enbart ettor. När man sedan skriver till sektorn sker det genom att nolla de celler som ska innehålla nollor. Att omvandla en nolla till en etta kräver däremot att hela sektorn raderas, och eftersom skrivningar normalt innebär att detta behövs, kan man lite förenklat uttrycka det som att en skriven sektor måste raderas innan den kan skrivas igen. På NAND-flash finns dessutom komplikationen att radering sker på blocknivå medan skrivning sker på sidnivå, där varje block innehåller multipla sidor. För att slita på NAND-flash så lite som möjligt är det därför bäst att vänta med radering av ett block tills alla dess sidor är skrivna. Hur som helst behöver kontrollern hålla reda på vilka block som är raderade och inte, och när den vet att en sida ligger på ett raderat block kan den ju presentera detta som "enbart nollor" för datorn även om det ser annorlunda ut rent fysiskt.
Det låter som du har bättre koll än jag på hur det fungerar rent elektriskt. Dock förstår jag inte hur jag skall tolka ditt svar. Förstår jag dig rätt i att det är "sidor" som representerar de logiska blocken, medan fysiska block består av flera sidor? TRIM-kommandon kommer i regel att vara slumpmässigt utspridda eftersom man inte defragmenterar SSD-baserade filsystem och det kommer i så fall vara tämligen ovanligt att samtliga sidor som tillhör samma fysiska block kan frigöras, åtminstone om filsystemet är fyllt till 50% eller mer. Hur kan man då radera blocken i förväg utan att det blir oekonomiskt?
Citera
2018-11-23, 20:49
  #9
Medlem
Citat:
Ursprungligen postat av WbZV
Det låter som du har bättre koll än jag på hur det fungerar rent elektriskt. Dock förstår jag inte hur jag skall tolka ditt svar. Förstår jag dig rätt i att det är "sidor" som representerar de logiska blocken, medan fysiska block består av flera sidor?

Terminologin är lite förvirrande eftersom termer som "block" och "sidor" används inom olika områden som ibland tangerar varandra. I OS/filsystemssammanhang menar man t.ex. något annat med "block" och "sidor" än när man pratar om flashkretsar, och när ett filsystemsblock lagras i en flashkrets är det upplagt för förvirring eftersom det inte finns något 1:1-förhållande mellan begreppen. I praktiken brukar dock filsystemsblock numera vara mindre än flashblock men större än flashsidor. En SSD-disk har därför ett översättningslager i flash-kontrollern som döljer detaljerna i hur lagringen sker i flashminnet, så att den utåt sett ser ut att fungera som en vanlig roterande hårddisk. Via översättningslagret kan man också sprida slitaget över hela flashen, eftersom ett visst filsystemsblock (t.ex. ett som uppdateras ofta) kan mappas till olika ställen i flashen med tiden.

Citat:
Ursprungligen postat av WbZV
TRIM-kommandon kommer i regel att vara slumpmässigt utspridda eftersom man inte defragmenterar SSD-baserade filsystem och det kommer i så fall vara tämligen ovanligt att samtliga sidor som tillhör samma fysiska block kan frigöras, åtminstone om filsystemet är fyllt till 50% eller mer. Hur kan man då radera blocken i förväg utan att det blir oekonomiskt?

Moderna SSD-diskar implementerar "garbage collection" som ser till att spridda skvättar av ledigt utrymme kombineras till sammanhängande block som kan raderas. Dock skulle jag tro att det även är rätt vanligt att helt lediga block uppkommer spontant till följd av att filsystem brukar föredra att allokera sammanhängande utrymme för filer, vilket gör att sammanhängande utrymme också blir ledigt när respektive fil raderas (vilket SSD:n blir informerad om via TRIM). Det är i så fall att föredra framför "garbage collection", eftersom det senare innebär en viss kopiering och därmed slitage när data flyttas runt.
Citera
2018-11-23, 21:03
  #10
Medlem
Citat:
Ursprungligen postat av vgebler
Terminologin är lite förvirrande eftersom termer som "block" och "sidor" används inom olika områden som ibland tangerar varandra. I OS/filsystemssammanhang menar man t.ex. något annat med "block" och "sidor" än när man pratar om flashkretsar, och när ett filsystemsblock lagras i en flashkrets är det upplagt för förvirring eftersom det inte finns något 1:1-förhållande mellan begreppen. I praktiken brukar dock filsystemsblock numera vara mindre än flashblock men större än flashsidor. En SSD-disk har därför ett översättningslager i flash-kontrollern som döljer detaljerna i hur lagringen sker i flashminnet, så att den utåt sett ser ut att fungera som en vanlig roterande hårddisk. Via översättningslagret kan man också sprida slitaget över hela flashen, eftersom ett visst filsystemsblock (t.ex. ett som uppdateras ofta) kan mappas till olika ställen i flashen med tiden.

Moderna SSD-diskar implementerar "garbage collection" som ser till att spridda skvättar av ledigt utrymme kombineras till sammanhängande block som kan raderas. Dock skulle jag tro att det även är rätt vanligt att helt lediga block uppkommer spontant till följd av att filsystem brukar föredra att allokera sammanhängande utrymme för filer, vilket gör att sammanhängande utrymme också blir ledigt när respektive fil raderas (vilket SSD:n blir informerad om via TRIM). Det är i så fall att föredra framför "garbage collection", eftersom det senare innebär en viss kopiering och därmed slitage när data flyttas runt.
Tack för klargörandet!

Kontentan blir i alla fall att datan går delvis förlorad när man raderar filer. Men för att vara helt säker på att inga kvarvarande fragment går att återställa så behöver man köra secure erase på hela disken.
Citera

Skapa ett konto eller logga in för att kommentera

Du måste vara medlem för att kunna kommentera

Skapa ett konto

Det är enkelt att registrera ett nytt konto

Bli medlem

Logga in

Har du redan ett konto? Logga in här

Logga in