SSD disk - postupná ztráta výkonu

[Nevitidelný]

Okay, tohle dává smysl. Takže v důsledku wear levelingu se rozfragmentují a přemapují jinak po sobě jdoucí sektory, což je důvod špatného výsledku z hdparm -t? Jestli je tohle pravda, proč původnímu tazateli pomohlo jenom urvat z konce disku pár GB a posunout začátek oddílu? Na už silně fragmentovaném disku bych čekal, že pomůže jen úplný wipe a udělat všechno nanovo se správným nastavením...

[Reklama]

[Nevitidelný]

Takže v důsledku wear levelingu ...

Wear levelingu A nefuknčního TRIMu... (wear leveling se provádí vždycky)

[Tomas Dvorak]

Funkční trim je základní předpoklad zachování ssd disku zdravého.

Nemyslím si, že byl trim nefunkční (alespoň podle testu http://andyduffell.com/techblog/?p=852). Volného místa měl disk taky dostatek, i když pravda, že uvnitř partition. Zatím si tedy myslím, že zabralo to posunutí partition o pár MiB dozadu. Tím se data překopírovala a v podstatě defragmentovala (je to s gparted možné?). Teď jsem zvědav, jestli změna zarovnání a cca 10% volného místa mimo partition dovedou udržet disk na stejném výkonu dlouhodobě.

[lt]

Nejaky clanok o SSD by sa hodil a mozno aj nejake nastavenie na windowse :-). Ale zaujimalo by ma toho viac, napriklad stabilita informacie. Ked som uvazoval o zalohe fotiek co by vydrzala dlho najlepsie my vychadzala compact flash karta. Pretoze ju zacali vyrabat v roku 1994 a uz 20 rokov su na nu v pocitacoch konektory, tak je cekom mozne ze dalsich 20 rokov aj zostanu. Na CF nema ani CD ( 10 rocne cd sa bojim dat do mechaniky ze sa rozleti) alebo disketa (lebo uz ziadnu mechaniku nemam), USB specifikaciu menia v kuse a ATA konektor na doske tiez uz nikto nenajde. Mam CF(4MB) co su na nej fotky okolo 10 rokov ale vydrzia aj dalsich 10?

ATA konektor nie je problem ani dnes cez redukciu, USB tiez nie.
Flash pamat ma jednu vaznu nevyhodu a sice postupna strata naboja, takze na CF by som sa velmi nespoliehal. Dnesne SSD consumer level disky maju tusim garanciu 1 alebo max. 2 roky , ze vydrzia uchovat informacie bez napajania, stare flashky asi 10 rokov.
Mam 20 rocne CD, nie je s nimi problem. V pohode sa daju citat. Pre archivaciu by som sa nespoliehal na nic, proste raz za cas presunut archiv inde, dnes , pokial toho nie je privela by som kludne pouzil aj nieco ako dropbox, gdrive a pod. , zasifrovane samozrejme.
Najistejsia cesta ako spolahlivo archivovat je nechat to warezakom .. ale ak mas 4MB fotiek, tak to si mozes archivovat skutocne hocikde na webe.

[JmJ]

Nejaky clanok o SSD by sa hodil a mozno aj nejake nastavenie na windowse :-). Ale zaujimalo by ma toho viac, napriklad stabilita informacie. Ked som uvazoval o zalohe fotiek co by vydrzala dlho najlepsie my vychadzala compact flash karta. Pretoze ju zacali vyrabat v roku 1994 a uz 20 rokov su na nu v pocitacoch konektory, tak je cekom mozne ze dalsich 20 rokov aj zostanu. Na CF nema ani CD ( 10 rocne cd sa bojim dat do mechaniky ze sa rozleti) alebo disketa (lebo uz ziadnu mechaniku nemam), USB specifikaciu menia v kuse a ATA konektor na doske tiez uz nikto nenajde. Mam CF(4MB) co su na nej fotky okolo 10 rokov ale vydrzia aj dalsich 10?

ATA konektor nie je problem ani dnes cez redukciu, USB tiez nie.
Flash pamat ma jednu vaznu nevyhodu a sice postupna strata naboja, takze na CF by som sa velmi nespoliehal. Dnesne SSD consumer level disky maju tusim garanciu 1 alebo max. 2 roky , ze vydrzia uchovat informacie bez napajania, stare flashky asi 10 rokov.
Mam 20 rocne CD, nie je s nimi problem. V pohode sa daju citat. Pre archivaciu by som sa nespoliehal na nic, proste raz za cas presunut archiv inde, dnes , pokial toho nie je privela by som kludne pouzil aj nieco ako dropbox, gdrive a pod. , zasifrovane samozrejme.
Najistejsia cesta ako spolahlivo archivovat je nechat to warezakom .. ale ak mas 4MB fotiek, tak to si mozes archivovat skutocne hocikde na webe.

Cf karta rozhodne neni na archivaci vhodna. Napr. karty advantech urcene udajne pro prumyslove pouziti zacnou mit problemy uz po pul roce (i driv) lezeni ve skladu bez napajeni. Overeno testy.

[Reklama]

[Kolemjdoucí]

Mam CF(4MB) co su na nej fotky okolo 10 rokov ale vydrzia aj dalsich 10?

Nic z technologie Flash není určeno pro zálohování, naopak se přímo počítá s tím že záznam se samovolně ztratí. Flash můžete vzít na milost jedině tak, že 1x za rok flash smažete a zapíšete data znovu.
Na zálohování jsou HDD, DVD-RAM, pásky a podobně.

[to_je_jedno]

ale ak mas 4MB fotiek, tak to si mozes archivovat skutocne hocikde na webe.

by mel asi nejlepsi to vytisknout jako HEX laserovkou a zalaminovat.

[Neviditelný]

Nedalo mi to a trochu jsem na svém 840 EVO 250 GB experimentoval. Když jsem včera zkoušel minibenchmark hdparmu, vyhodil něco okolo 120 MB/s. Nejdřív jsem updatoval firmware na verzi EXT0BB6Q, která dle webu Samsungu vypadá jako nejnovější. To samozřejmě vůbec nepomohlo. Podle návodu výše jsem z Live CD ověřil funkci trimu. Když jsem oddíl připojil s volbou "discard", byl příslušný sektor za chvíli vynulovaný. Bez "discard"u se to nestalo. fstrim ale fungoval. Předpokládám tedy, že trim fungoval celou dobu dobře.

fstrim se chová trochu zvláštně. Když jej spustím poprvé, chvilku se něco děje a výstup ukáže, kolik bytů se zatrimovalo (cca 80 GB na jednom oddílu, přes 11 GB na druhém). Opětovné spuštění vrátí nuly a proběhne okamžitě. Stačí ale oddíl odpojit a připojit znovu a celý cyklus se opakuje, vrácené hodnoty zatrimovaných bytů jsou pokaždé stejné. Když jsem oddíl připojil bez "discard"u a vytvořil a smazal nějaký soubor, byla vrácená hodnota zatrimovaných bytů větší. Po dalším remountu se vrátila na původní, takže i fstrim nejspíš funguje, jak má.

Na disku je kromě miniaturního ef02 oddílu root, /home (oba ext4) a swap. Over-provisioning jsem nezapínal, ale na / je 55 % volného místa, na /home 43 %. Během psaní příspěvku jsem smazal nějaký bordel, cache pacmana atp. a schválně spustil benchmark znovu. Výsledek mě celkem zaskočil, ale totéž jsem dostal i po restartu:
/dev/sdb: 232 MB/s
/dev/sdb2: 253 MB/s (/)
/dev/sdb3: 271 MB/s (swap)
/dev/sdb4: 245 MB/s (/home)

Disk je připojen na staré SATA II rozhraní, takže cokoliv nad 250 MB/s mi přijde OK. Netroufám si odhadovat, co se stalo, že by to bylo novým firmwarem?

[Tomas Dvorak]

fstrim se chová trochu zvláštně. Když jej spustím poprvé, chvilku se něco děje a výstup ukáže, kolik bytů se zatrimovalo (cca 80 GB na jednom oddílu, přes 11 GB na druhém). Opětovné spuštění vrátí nuly a proběhne okamžitě. Stačí ale oddíl odpojit a připojit znovu a celý cyklus se opakuje, vrácené hodnoty zatrimovaných bytů jsou pokaždé stejné.

Děje se mi to samé, včera jsem to několikrát zkoušel a výsledek fstrim vždy jako u tebe. Proč, to nevím. Firmware jsem zatím neřešil.

[trubicoid2]

no tak pripojeni a odpojeni vzdy i zapise nejaka metadata do fs, tim padem je co trimovat

mas discard u swapu? ve fstabu? v dmesg je pak neco takovyho:

Kód: [Vybrat]

Adding 16777212k swap on /dev/sda4.  Priority:-1 extents:1 across:16777212k SSDscFSto SSDscFS je dulezity

a ten over-provisioning si zapnete; samsung to neudelal uplne chytre, kdyz dovolil uplne vypnuti a navic kdyz to linuxovy distribuce tak defaultne udelaji

Předpokládám tedy, že trim fungoval celou dobu dobře.

fstrim se chová trochu zvláštně. Když jej spustím poprvé, chvilku se něco děje a výstup ukáže, kolik bytů se zatrimovalo (cca 80 GB na jednom oddílu, přes 11 GB na druhém).

no nevim, jestli se trimuje 92GB z 256GB, tak asi discard moc nefunguje, dej fstrim do crontabu a hotovo, pak nepotrebujes discard ve fstabu (jen u swapu)

[Tomas Dvorak]

no nevim, jestli se trimuje 92GB z 256GB, tak asi discard moc nefunguje, dej fstrim do crontabu a hotovo, pak nepotrebujes discard ve fstabu (jen u swapu)

Divné je, že po prvním spuštění fstrim hlásí, že trimoval (třeba těch 92G), po druhém spuštění hlásí 0. Pak unmount / reboot a znovu spustit fstrim - opět trimováno 92G. Proč? V mém případě swap vůbec nemám, discard ve fstab pro / ano.

[Neviditelný]

no nevim, jestli se trimuje 92GB z 256GB, tak asi discard moc nefunguje, dej fstrim do crontabu a hotovo, pak nepotrebujes discard ve fstabu (jen u swapu)

Divné je, že po prvním spuštění fstrim hlásí, že trimoval (třeba těch 92G), po druhém spuštění hlásí 0. Pak unmount / reboot a znovu spustit fstrim - opět trimováno 92G. Proč? V mém případě swap vůbec nemám, discard ve fstab pro / ano.

Přestě takhle se mi to chová. Chápu, kdyby zatrimoval pár kB na ne půlku disku...

Trim by se na swapu měl snad aktivovat automaticky, ale v mém případě se tak nejspíš neděje. Po bootu mám v dmesg jen "SSFS", přestože v fstabu mám u /dev/sdb3 "defaults,discard". Pokud swap nahodím ručně přes "swapon --discard /dev/sdb3", dostanu "SSDscFS". Swap mi mountuje systemd, nemusí se tedy ten parametr nastavit někde jinde? To by asi ty výkonnostní problémy z části vysvětlilo...

Overprovisioning nahodím, až budu mít čas přeinstalovat systém...

[trubicoid2]

u systemd nevim kde mu to vnutit  urcite necte /etc/fstab? da se to poznat, ze mu tam das discard,prio=-10 a potom v /proc/swaps by melo byt Priority -10

divny je, ze se trimuje tolik, to je vsechno volny misto? ted zrovna pocitac nemuzu restartovat, neco mi to pocita, ale pak to zkusim

mate oba ubuntu a ext4? nebezi tam traba defragmentace e4defrag?

[Neviditelný]

Já mám Arch, defragmentace ext4 neběží. Nefunkční trim na swapu je pochopitelně bug v systemd(https://bugzilla.redhat.com/show_bug.cgi?id=987136), uvidím, zda pomůže změnit typ oddílu na 8300.

[Tomas Dvorak]

Já ubuntu (14.04), ext4, defragmentaci jsem nikdy nespouštěl, nenastavoval, tak pokud někde není defaultně, určitě nikdy spuštěná nebyla. U mě ta hodnota opravdu odpovídá volnýmu místu na partition.