Lagringsdisk - SSD eller HDD 2023?

Jag var tvungen att kolla, hade ett Asus P5Q PRO och det hade faktiskt bara SATA 2 d.v.s. 3 Gbit/s, så det är jag som blandat ihop siffrorna efter alla dessa år. Hittade även ett gammalt Sweclockers-test från sommaren 2010, och där är det SATA 2 rakt av i alla enheter de testade: https://www.sweclockers.com/test/12326-ssd-sommaren-2010/

Jag var ju själv ganska sen med SSD, första jag köpte var en 240 GB Intel 520 strax efter att de kom ut på marknaden våren 2012, och då bytte jag dator i samma veva.

Kul hur långt vi har kommit sedan dess.

Ja vad tror du... för att man kan köpa 2st.

Fast argumentet gällde ju "sub 10TB". Totalt, som jag tolkar det, inte per disk.

Windows kör en 'optimize' typiskt söndagar (inget som du ser normalt) vilket både inkluderar TRIM på all ledig diskutrymme för att ta det som missats eller inte kunde genomföras av SSD/NVMe vid just tidpunkten (dvs. datat är kvar och inte nollad vid läsning på adresser där nu raderade filer tidigare låg) när trim utförs för filer som raderas. Men det gör också en defragmentering av filer som har väldigt många fragment och det är för att NTFS skall överleva på längre sikt och inte hamna i issue som att en fil inte kan ökas på i storlek eller att det går inte att lägga in ytterligare filer i en filmapp för att de är väldigt, väldigt fragmenterade (NTFS hanterar max ca 1.5 miljoner fragment per fil och formaterad med flagga /L klarar den 6 miljoner fragment men då på bekostnad att var fil-entry nu tar 4KB istället för 1kB i $MFT)

Dessutom fragmenterar VSS (aka shadowcopy) väldigt mycket och måste hanteras för att inte ge problem framöver.

MS kallar inte processen för 'defragmentera' för att ordet är stigmatiserat i SSD/NVMe-sammanhang utan man kallar det för 'optimize'... och det är själva NTFS som behöver detta för sin överlevnad, inte SSD/NVMe i sig.

Även en del Linux-distubitioner som Ubuntu kör veckovis schemalagd 'fstrim' på all monterad SSD/NVMe-lagring men där kör man normalt inte TRIM när filer raderas, även om det går att få in sådant som parameter i fstab mfl. ställen.

Motivationen i alla fall tidigare att inte göra TRIM/discard i Linux när filer raderas är att när SSD gör TRIM så blockeras lagringen under processen och ingen läsning eller skrivning kan göras under tiden och var det stora block som skulle raderas så kunde det ta många sekunder innan lagringen svarade igen. När windows kör trim på stora filer som raderas så sprider de ut TRIM-kommandona i mindre block och kan pågå i flera minuter efter att en stor fil har raderats.

På PCIe-NVMe så skall det inte blockera enligt specifikation men det är inte säkert att alla program som hanterar TRIM förstår det utan väntar på färdigkvitto.

---

Filsystem som ext4 behöver man inte köra defragmentering på och även på väldigt mogen filsystem så är fragmenteringen sällan mer än max någon procent, och det är inte så konstigt då ext3/ext4 utvecklades så hade man NTFS som lärobok i hur man inte skulle konstruera filsystem...

BTRFS kan man behöva köra en defragmentering i och med att det är en COW-filsystem så kommer det att fragmentera, men om jag skall vara ärlig så har jag aldrig känt behov av det baserat på prestanda hittills, det är möjligen ett fall där det märks skillnad och det är att defragmentera metadatan så att en sökning med 'find' av ca 1 miljon filer i mer eller mindre djupa trän går på 1.4 sekunder istället för 5.7 sekunder (metadata dock inläst i RAM av tidigare sökning - gör man den första sökningen på nystartad dator kanske det tar 30-40 sekunder läst från snurrdiskar och det är nog den delen man kan kan korta mest märkbart med en defragmentering av metadatan.)

Tack för lång teknisk utläggning.

Vad jag snappat upp över tid är att modernare kontrollers inte behöver "hjälp" att utföra dessa sysslor utan att de sker direkt när det inte är någon annan aktivitet, därav även att knappen "Optimize" har försvunnit från ett flertal SSD-programvaror som skickas med/kan laddas hem för olika enheter. Intel hade kvar det i sin mjukvara SSD Toolbox, sannolikt eftersom de var väldigt tidigt ute med SSDs som fortfarande används. Knappen finns även i Solidigm (som "Intel-SSDs" heter nu) Storage Tool, men även efter kopiering/användning så blir det klart typ samtidigt som man tycker på knappen. Gamla Intel-SSDs stod ju och jobbade en liten stund när man körde Optimize även om man gjorde det manuellt en gång i veckan.

Jag tror mycket av eventuella behov av TRIM döljs av att SLC-cachen är typ 25-50 GB stora på dagens 1-2TB stora SSD/NVMe och vid normal användning så blir den inte full ens av en BR-image som skickas in snabbt på lagringen, men skall man dumpa en diskimage på 1TB så kommer man märka de olika trösklarna i skrivhastighet även på en modern konsument-SSD/NVMe både när skriv-cachen tar slut, eventuell värmetrottligt etc. och är inget som syns på de första 50 GB data skriven.

sedan är frågan vad som menas med moderna minnen - det som säljs idag, eller de som är 1-2 år gamla

#19962739

Är start på tråden där prestandan blev dålig över tiden för att TRIM inte körts på länge för att TS hade slagit på filsystemskomprimeringen i windows i något svagt ögonblick med ont om plats i lagringen utan vetskap att det också stängde av TRIM-hanteringen mot lagringen. Andra fällor som också stänger av TRIM är att använda sig av moderkortets RAID-funktioner och windows ser logiska volymer och inte SCSI-disk eller AHCI-enheter och då skickas heller inga TRIM-kommandon.

Stor skillnad på att ha 2x4 vs 1x8, dels när det gäller att ha plats/kontrollers och dels när det gäller hur man styr upp lagringen så att man kommer åt allt som en stor disk. Dessutom så kostar ju då en 4Tb HDD bara runt 1k så 4x så dyrt ändå.

tänk om man vill köra speglat då (kör ju själv speglat på alla diskar), då måste du till med 4st 4Tb SSD:s för att ersätta 2st 8Tb HDD och priset skjuter plötsligt i höjden plus att du inte längre får 8Tb lagring utan 2x4 som du måste manuellt rodda med.

ja 4st 4TB:s SSDs mot 2st 8TB HDD:s är ju inget som helst prisskillnad och nu har folk försökt försvara den dåliga strategin ända tills anklagelser om att man inte kör backup bara för att man råkar köra speglat... Oboy.

Spegling/RAID är ingen backup - men det vet ni redan och en snabb skriven "rm -rf / usr/local/junk"[1] som sudo/root räddar inte några filer oavsett RAID1/5/6/10/50/60.[2]

[1] modernare 'rm' accepterar inte en ensam '/' utan forcerande flaggor - och det finns en anledning till det...
det finns flera och ännu snyggare och inte alltid så uppenbara kommandoradsmissar med mer eller mindre katastrofala konsekvenser, men hittar inte sådana just nu...

[2] en skapad BTRFS-subvolym tagen med "btrfs su snap -r mapp mapp_snapshot" som root så överlever "mapp_snapshot" efter en 'rm -rf /' även körd som root då inga vanliga filoperationer kan påverka innehållet i denna och mappen måste först låsas upp av en BTRFS-kommando innan någon alls kan ändras i mappen.

Tror skillnaden mellan HW och mjukvaru-RAID är mindre i prestanda/CPU-förbrukning upp till viss storlek/antal diskar.

Är det kopplat till SAN och väldigt många diskar så blir det annat läge, men å andra sidan har filsystem som ZFS och BTRFS egna strategier som inte alltid går väl ihop med hur HW-RAID-kontroller arbetar.

Och har man S3-liknande molntjänster implementerat som minio så är det redan där mycket redundans inbyggt och fokus är snarare på så enkla och snabba filsystem (som ext4) på var disk som möjligt utan någon RAID-struktur alls mellan diskarna och det ligger i minio/annan molntjänstserver att hantera och där byter man inte diskar som gått sönder utan kör tills redundansen gått ned under en viss nivå räknat i antal fungerande diskar och sedan bygger man om alltihop på ny lagring.

En kollega på jobbet råkade ut två gånger för att hans ssd gick till read-only-mode. Den brickades inte men gick inte att boota windows pga att det inte gicka att skriva på den. Gick dock att dumpa innehålllet på en annan disk med linux o så var han igång igen.
Körde mycket kompileringar så hann slita ut minst två ssd:er.

Finns ju PaperBack, upp till 500 kb/sida:

https://www.extremetech.com/extreme/134427-a-paper-based-back...

Jodå, i min ungdom när jag körde XENIX på ett z8000 system så skulle jag göra rm *.lst
Nu var det på konsolen jag körde så mitt i mitt skrivande så kom det upp en massa systemmeddelanden, kommandot blev i stället
rm * .lst

Suck, bara ta fram senaste backup

Ett trix om man är osäker på vilka filer som 'rm' vill ta bort (vilket inte alltid går att prova först med harmlösare kommando som 'ls') men att det inte verkställer borttagande av filen och därmed kan få en listning vilka filer som verkligen ingår i kommandot:

"yes no | rm -i -rf /sökväg/"

programmet 'yes' med parametern 'no' sänder hela tiden 'no'-rader till en pipe

'rm' med '-i' flaggan (interactive) väntar på en 'yes' för var fil som skall tas bort, annars blir den kvar

och med arragemangen när 'rm' läser från pipe (i stället för att skriva 'no' i tangentbordet för varenda fil) som bara levererar rader med 'no', nekar att filer tas bort och man få listan över vilka filer som 'rm' tycker sig vilja ta bort.

Symboliska länkar kan också ge käftsmäll som känns med tex. 'rm -rf symboliska_länken' så tar den bort själva länken men med 'rm -rf symboliska_länken/' (en 'TAB' för mycket i filnamnskomplettering i Bash) så tar det bort allt som länken pekar till och är det till en filmapp, så försvinner allt under det också - och det är system-wide och spärras inte av om det är på samma disk eller inte, så det går bra att tömma en monterad NAS-innehåll också.....

jag har gjort det med .ecryptfs i någon backupfilträd på annan media som jag städade efter att 'rmlint' hade gjort sitt - sedan gick det inte att logga in på ubuntu-desktopen på datorn längre...

Reminder: uppmaningen att man skall spara huvudnyckeln för sin krypterade hemkonto och lagra på annan säkert ställe när kontot skapas, är en uppmaning man skall ta väldigt seriöst på... och tillägga att kör man 'root' lite för ofta och mycket så blir det konsekvenser att hantera när man gör fel... stor makt medför också stor ansvar...

---

En väg är också att köra med 'find' och kolla vilka filer som den hittar och sedan när rätt filer visas, skickas till rm med -exec rm {} eller vid större antal filer: xargs, med -0 option, om fillistorna som skapas av find är väldigt stora.

xargs hackar upp väldigt stora fillistor som tex från sökning med 'find' ger till lagom portioner som tex 'rm' kan ta genom att de körs upprepande.

användning med -fprint0 i find och flagga -0 i xargs är för att alla texter som skickas med tex. find bryter på null-terminering av rader och inte fastna på filnamn med mellanslag eller mer exotiska tecken i filnamnen som någon eller flera av |\[]()=?*'#¤"!'` som annars kan försökas tolkas i kommandot och ställa till och hacka upp filnamnen oväntat och det blir mer eller mindre (katastrofalt) än det man tänkt...

---

med 'rsync' så är det väldigt bra att prova med "--dry-run" först och speciellt om man också har flaggan --delete på kommandolinjen innan man kör det på riktigt - en missad eller en för mycket '/' i slutet av sökvägen på källan/målet kan göra att hela backuppen/speglingen på målsidan försvinner, det hinner göra väldigt många 'delete' av filer på väldigt kort tid innan man inser fadäsen...

Jag gillar verkligen att först köra 'btrfs su snap -r orginalfilspeglingen snapshotsfilpegligen_datum' innan man kör rsync...

De flesta har en uppfattning om vad som menas med nanosekunder vid tidmätning - men det är mindre känt att 'oh-nej sekunder' är betydligt kortare...

"konstiga" ljud vid start säger faktiskt inte så mycket om de är på gång att gå sönder eller inte, om man bortser från vissa typfall för vissa serier av diskar - hade en disk som under läs-sökning kunde tjonga till ordentligt i ändlägen med sin läsarm ganska ofta och hade ett vinande ihållande ljud i flera minuter då och då som lät som att lagret var på väg att skära och man tänkte att den nog inte skulle hålla länge till - den var fortfarande igång 7 år senare och byttes pga. storleken var för liten...

SMART är fortfarande den bästa stället att se om disken mår bra eller inte - speciellt för fel som inte hörs akustiskt och som förekommer betydlig mer ofta som ökande antal oläsbara sektorer och reallokeringar av sektorer.

Men jag föredrar detta att de ger oljud och börja kanske ha läsproblem med långsammare läsningar och kan pågå under ganska lång tid (halvår till åratal) innan faktiska problem (och man har lång tid på att kunna göras backup) än SSD:s beteende att en dag som blixt från klar himmel inte svara alls och helt utan förvarning.