Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: Tomas Dvorak 18. 08. 2014, 07:30:42
-
Zdravím,
před zhruba 3 měsíci jsem pořídil nový SSD disk Samsung SSD 840 EVO - 120GB. Běží v desktopu, na desce ASUS H81M-K. Na začátku vypadaly testy výkonu perfektně, tak, jak sliboval výrobce.
sudo hdparm -tT /dev/sda1
Timing cached reads: 17826 MB in 1.99 seconds = 8945.58 MB/sec
Timing buffered disk reads: 1548 MB in 3.00 seconds = 515.63 MB/sec
Nedávno jsem zaznamenal, že systém je nějaký pomalejší a napadlo mě otestovat znovu výkon. A pohybuje se okolo 30% původních rychlostí:
Timing buffered disk reads: 456 MB in 3.01 seconds = 151.30 MB/sec
Na disku je 50% volného místa, trim aktivovaný a funguje, nic v konfiguraci se neměnilo. Systém je Ubuntu 14.04. Narazil jsem na fórum, kde řeší stejný problém: http://www.tomshardware.co.uk/answers/id-1862865/840-evo-performance-dropped.html
Nenapadá vás, jestli jde skutečně o HW problém a disk je na reklamaci? Setkali jste se s podobným chováním?
Mockrát díky.
-
Mas TRIM aktivny na vsetkych urovniach?
Musi byt samostatne zapnuty pre particiu, pre lvm2, pre dmcrypt, ... a dalsie layery ktore su medzi datami a diskom.
-
Mas TRIM aktivny na vsetkych urovniach?
Musi byt samostatne zapnuty pre particiu, pre lvm2, pre dmcrypt, ... a dalsie layery ktore su medzi datami a diskom.
Díky za odpověď, konfigurace je v mém případě strašně jednoduchá. Disk má jedinou partition, na které sedí ext4 (namountovaná s discard). Neprovozuji žádné šifrování, raid ani lvm. Jestli trim funguje jsem ověřoval třeba podle návodu http://andyduffell.com/techblog/?p=852
-
Co je to ztrata vykonu? Ztrata cisel v benchmarku je totiz neco jineho. Pozorujes nejak subjektivne nebo objektivne pri praci zpomaleni systemu apod?
Chyba byla IMHO ve vyberu kastrovaneho SSD ktere si v necem hraje na neco co neni.
-
Co ti vypíše:
sudo fstrim -v /
Změní se po výše uvedeném příkazu výkon?
-
Co ti vypíše:
sudo fstrim -v /
Změní se po výše uvedeném příkazu výkon?
Doběhne to v podstatě okamžitě, vypíše, kolik bytes bylo trimmnuto (cca 50GB), výkon se nijak nezmění. Opakované spuštění vypadá vždy stejně (podobné číslo, stejně rychlý běh). Testoval jsem to už před několika dny, nechal disku i čas se s operací vypořádat a žádná změna.
-
Co je to ztrata vykonu? Ztrata cisel v benchmarku je totiz neco jineho. Pozorujes nejak subjektivne nebo objektivne pri praci zpomaleni systemu apod?
Chyba byla IMHO ve vyberu kastrovaneho SSD ktere si v necem hraje na neco co neni.
Pozoruji znatelně pomalejší například start a indexování projektů v Intellij IDEA (mnoho malých souborů) - proto jsem začal hledat, kde je problém. S výběrem disku už teď nic nenadělám. Teď řeším, jestli je takové chování v pořádku nebo se jedná o závadu nebo špatnou konfiguraci.
-
Evo :-\
Zkontroloval bych si vetsi firmware a cvičně bych výkon přeměřil hned po rebootu.
-
Schválně jsem si zkusil spustit fstrim u mne (i když mám v fstabu discard) a:
fstrim -v /
/: 3446231040 bajtů bylo zahozeno
fstrim -v /
/: 0 bajtů bylo zahozeno
Poprvé to trvalo opravdu dlouho, až jsem si myslel, že se to kouslo. Podruhé to proběhlo téměř okamžitě (nebylo co zahazovat). Pokud se po opakování příkazu nic nemění, tak je to divné. Prvně bych zkusil zjistit, proč se to nemění.
-
Disk má jedinou partition, na které sedí ext4 (namountovaná s discard).
V tom by mohl byt problem: operace trim/discard trva nejakou dobu a pouzitim mount volby 'discard' tak neni obecne doporucovane. Zkusil bych odstranit disrard z fstabu a misto toho spousted trim jako cron job jednou denne nebo tydne - melo by to uplne stacit.
-
Schválně jsem si zkusil spustit fstrim u mne (i když mám v fstabu discard) a:
fstrim -v /
/: 3446231040 bajtů bylo zahozeno
fstrim -v /
/: 0 bajtů bylo zahozeno
Poprvé to trvalo opravdu dlouho, až jsem si myslel, že se to kouslo. Podruhé to proběhlo téměř okamžitě (nebylo co zahazovat). Pokud se po opakování příkazu nic nemění, tak je to divné. Prvně bych zkusil zjistit, proč se to nemění.
To je zajímavé. Zkoušel jsem teď na jiném PC s SSD a chová se to stejně, jako popisuješ. Napoprvé to jelo poměrně dlouho, napodruhé skončilo hned a také vypsalo 0. Na problematickém disku to vypisuje stále vysoké hodnoty i při opakovaném spuštění. Zkusím se odrazit od toho, díky za tip.
-
Viz discard mount option:
https://patrick-nagel.net/blog/archives/337
http://oss.sgi.com/pipermail/xfs/2011-November/015320.html
-
Viz discard mount option:
https://patrick-nagel.net/blog/archives/337
http://oss.sgi.com/pipermail/xfs/2011-November/015320.html
Já vím, že spouštět fstrim v cronu by bylo asi lepší z hlediska rychlosti, a u intenzivně používaného disku by byl asi rozdíl patrný. Nicméně při běžné práci snad rozdíl poznat není? Lekl jsem se, že někdo objevil, že discard v fstabu nějak disku škodí, ale to se snad zatím neprokázalo?
-
no a mas zapnuty overprovisioning? to prej udela hodne, ale prijdes o cast kapacity
bez nej mas sice vic mista, ale bude se to zpomalovat
ja to mam treba na 250GB 840Pro takto:
hdparm -N /dev/sde
/dev/sde:
max sectors = 450106372/500118192, HPA is enabled
doporucuju vse zalohovat, disk smazat pomoci hdparm secure erase (treba http://www.thomas-krenn.com/en/wiki/SSD_Secure_Erase)
zapnout HPA a tim i overprovisioning (treba http://www.thomas-krenn.com/en/wiki/SSD_Over-provisioning_using_hdparm)
udelat partice, naformatovat, obnovit zalohu
-
benchmark je treba tu:
http://www.anandtech.com/show/6489/playing-with-op
-
A neni jen spatne zarovnana partition? 840 EVO by mel mit EBS 1536 KiB, proto se doporucuje zarovnavat partitions na 6144 KiB. Taky to mam na svem EVO blbe - nekde se totiz uvadi EBS 2048 KiB - a vykon mi zdegradoval uplne stejne. Bohuzel ted nemam cas preinstalovavat system...
-
Evo :-\
Zkontroloval bych si vetsi firmware a cvičně bych výkon přeměřil hned po rebootu.
Už druhý komentář, naznačující, že EVO je špatná volba. Pro příští lepší výběr - proč tak soudíte? V testech jej chválí a mám ho v obyčejném domácím pc, trocha vývoje, trocha brouzdání po internetu, multimedia. Nežhavím jej v serveru, nestahuju a nesdílím TB dat, nehraji hry. Jak tedy poznat špatný a dobrý disk?
Nezdá se mi, že bych po třech měsících příležitostného používání počítače mohl dostat disk na hranice jeho životnosti - brouzdáním po internetu a pár desítkama hodin vývoje.
Jinak výkon jsem měřil po rebootu, před rebootem i během práce. Po manuálním trimu i další den. A pořád plus minus stejné hodnoty.
-
A neni jen spatne zarovnana partition? 840 EVO by mel mit EBS 1536 KiB, proto se doporucuje zarovnavat partitions na 6144 KiB. Taky to mam na svem EVO blbe - nekde se totiz uvadi EBS 2048 KiB - a vykon mi zdegradoval uplne stejne. Bohuzel ted nemam cas preinstalovavat system...
Zarovnání jsem nijak zvlášť neřešil, partition vytvářel v gparted. Tedy nastaven 1MiB před, zarovnáno na MiB. Že by byl zakopaný pes v tom?
http://cillian.wordpress.com/2013/11/16/setting-up-samsung-840-evo-ssds-on-linux/
-
na Samsungu 830 mi padli IOPS po 3/4 roku asi na 10% povodneho benchmarku(pod windows) :-(
davam to reklamovat
-
na Samsungu 830 mi padli IOPS po 3/4 roku asi na 10% povodneho benchmarku(pod windows) :-(
davam to reklamovat
Reklamaci beru jako krajní řešení, až se ukáže, že chyba není v mém špatném nastavení. Přece jen, rád bych měl dostatek pádných argumentů, ne jen, že disk je nějaký pomalý.
-
830 je uplne jina liga nez EVO.
-
To zarovnani by se asi projevilo uz od zacatku. Navic o zarovnavani na 6M jsem jeste neslysel. Nejkonzervativnejsi zarovnavani je na 4M t.j. 8196 bloku. Velikost erase bloku se dala pouzit pri vytvareni ext4 jako stride, doma najdu link. Efekt je ale maly, srovnatelny s homeopatiky.
Jak mas nastavenej ten over-provisioning? Typuju mas to uplne vypnuty, to ani samsung nedoporucuje, a ted se divis :o
-
to: Trubicoid2
Takze na 840 EVO je doporucene mat ten over-provisioning. Ja to mam vypnute. (lebo doteraz som o nicom takom nevedel)
Celkovo by sa hodil nejaky lightovy clanok na rootu co si dat pozor u SSD na linuxe. Hlavne nejaky aktualny a komplexny.
-
Jak mas nastavenej ten over-provisioning? Typuju mas to uplne vypnuty, to ani samsung nedoporucuje, a ted se divis :o
Nastavený jsem to neměl nijak, o ničem takovým jsem neměl vůbec potuchy (je to můj první SSD) a samsung k tomu dodává jakousi sadu nástrojů, kde jsem se to mohl dozvědět a nastavit, ale jen pro windows.
Teď jsem tedy zmenšil tu jedinou ext4 partition a zároveň ji nechal 6MiB na začátku. Vzniklo 10G volnýho místa za, kde jsem vytvořil novou partition, naformátoval a poté smazal (jak doporučoval některý z návodů pro konfiguraci toho disku).
Výkon se vrátil na původní hodnoty:
sudo hdparm -tT /dev/sda1
/dev/sda1:
Timing cached reads: 18866 MB in 1.99 seconds = 9470.43 MB/sec
Timing buffered disk reads: 1548 MB in 3.00 seconds = 515.46 MB/sec
Otázka je, jestli to způsobil ten kompletní přesun partition o pár MiB dozadu, nebo dostatek volného místa na konci. Uvidím, jak do budoucna. Snad to není jen dočasné řešení :-) Zatím všem díky za tipy a rady.
-
to nevim, jestli staci mit misto pro over-provisioning jen vne partition table, mel jsem za to, ze by to melo byt HostProtectedArea, tak to mam ja
tys udelal na konci partici, naformatoval, udelal trim a partici smazal? tam asi zustane par jako obsazenych sektoru superbloku atd.
taky je lepsi smazat celej disk tim hdparm secure delete, jak jsem jiz byl psal, tim se disku rekne, ze vsechny bunky jsou volny a vykon bude jako u novyho
flack: over-provisioning je dobra a prakticky nutna vec na vsech ssd. nektery ssd to maj pevne nastaveny z vyroby, na samsungu si to muzes nastavit sam pres HPA a ve widlich pres ten jejich magickej software, koukni na benchmark.
ta slibovana magie se stride a stripe-width je popsana treba tu: http://wiki.gentoo.org/wiki/SSD
-
Celkovo by sa hodil nejaky lightovy clanok na rootu co si dat pozor u SSD na linuxe. Hlavne nejaky aktualny a komplexny.
K tomu se také přikláním.
Já o SSD na Linuxu vím úplný nic. Zatím jsem pořád ve stavu "nekupuj to, odejde to brzo". Jedu na Gentoo a předpokládám, že vše bych nastavoval hezky ručně. Když navíc vidím co je s tím za práci a jak se liší jednotlivý informace... Ne, děkuju.
Nejhorší je, že člověk v tomhle může poslechnout jen samý rady "jedna bába povídala" = z různých diskuzí, for, poraden a podobně, protože nikde není nic komplexního, kde by to vzali pěkně od podlahy se vším všudy.
-
to nevim, jestli staci mit misto pro over-provisioning jen vne partition table, mel jsem za to, ze by to melo byt HostProtectedArea, tak to mam ja
tys udelal na konci partici, naformatoval, udelal trim a partici smazal? tam asi zustane par jako obsazenych sektoru superbloku atd.
taky je lepsi smazat celej disk tim hdparm secure delete, jak jsem jiz byl psal, tim se disku rekne, ze vsechny bunky jsou volny a vykon bude jako u novyho
Asi by to bylo lepší, ale takhle jsem nemusel data zálohovat a měl jsem to za pár minut hotový s live ubuntu. Ve spoustě fór radí prostě nechat cca 10% volných bez partition na konci disku. Výkon teď super (jako nový), uvidím, jestli bude zas postupně degradovat. Pak bych to vzal kompletně jako jsi psal ty.
Ještě zkusím omrknout, jestli neexistuje nějaký update firmware.
Každopádně díky za rady a pomoc.
-
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?
-
Dává tenhle fix vlasně smysl? Trimování a extra volné místo na disku má zajistit, aby nedegradoval výkon při zápisu. Proč by se měl ale propadnout výkon při čtení? Benchmark hdparmu by navíc neměl být ovlivněn souborovým systémem nebo zarovnáním oddílů... co mi to tu uniká?
-
Uniká ti to, že bez trimu se to chová jako běžný disk, dojde k fragmentaci a pak místo 100 míst musíš přečíst 1000 míst, protože se čtení neprovádí náhodně po bitech, ale po blocích. Funkční trim je základní předpoklad zachování ssd disku zdravého.
-
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...
-
Takže v důsledku wear levelingu ...
Wear levelingu A nefuknčního TRIMu... (wear leveling se provádí vždycky)
-
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ě.
-
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 :D .. ale ak mas 4MB fotiek, tak to si mozes archivovat skutocne hocikde na webe.
-
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 :D .. 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.
-
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ě.
-
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.
-
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?
-
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.
-
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:
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)
-
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.
-
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...
-
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?
-
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.
-
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.
-
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.
Klid, brzy bude implementován systemd-trimd. O tom, jak kompetentně a s jak hlubokou znalostí fungování systému je vyvíjen tenhle frikulínský šmejd, odpovídá i inteligentní dotaz Lennarta, zda swapon čte /etc/fstab.
-
U mně je to o něco víc, free je ~97 GiB, trimuje se 101 GiB. (na /home)
-
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.
Klid, brzy bude implementován systemd-trimd. O tom, jak kompetentně a s jak hlubokou znalostí fungování systému je vyvíjen tenhle frikulínský šmejd, odpovídá i inteligentní dotaz Lennarta, zda swapon čte /etc/fstab.
V tomhle případě to ale možná tak nevadí, od jádra 2.6.35.5 se celý swap zatrimuje, když se spustí swapon. Parametr "--discard" pro swapon pouze zařídí, že se swap trimuje průbežně za běhu. Na strojích, které swapují jako o život to možná má význam, to ale není můj případ. Lennart se ptá jen na to, zda se parametr "discard" pro swap čte z fstabu, ne, zda swapon -a používá fstab. systemd generuje při startu unity pro mountování m.j. i z informací v fstabu, akorát v případě swapu jej zajímá jen parametr "priority".
-
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:
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)
-v, --verbose
Verbose execution. When specified fstrim will output the number
of bytes passed from the filesystem down the block stack to the
device for potential discard. This number is a maximum discard
amount from the storage device's perspective, because FITRIM
ioctl called repeated will keep sending the same sectors for
discard repeatedly.
fstrim will report the same potential discard bytes each time,
but only sectors which had been written to between the discards
would actually be discarded by the storage device. Further, the
kernel block layer reserves the right to adjust the discard
ranges to fit raid stripe geometry, non-trim capable devices in
a LVM setup, etc. These reductions would not be reflected in
fstrim_range.len (the --length option).
-
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.
Dakujem a aj vsetkym ostatnym za upresnenie mojej teorie o CF ako archivnom mediu. Naivne som si predstavoval ze budu mat problem len pri vesmirnom ziareni.
Tak ma napadlo ci nahodou firmware ssd disku po vypnuti a zapnuti napajania tiez z bezpecnostnych dovodov nepremiestni vsetky data niekam inam, aby obnovil naboj. To by mozno aj vysvetlilo to trimovanie celeho volneho miesta na disku po resete, ci to je dalsia prilis odvazna teoria? :)
-
Off topic alert:
Z niektorych prispevkov mam pocit ze kupa SSD vyzaduje magiu ako installacia Gentoo par rokov doazdu.
Moje primarne SSD som si kupil viac ako 2 roky doazdu... OCZ Vertex 4 128 GiB a je pravda ze som koli tomu spravil par drobnosti, ale nic extremne ako nechavat si miesto na konci disku.
*ziaden swap, pri dnesnych cenach RAM nema zmysel
*discard pre particiu, discard v crypttabe
*noatime
*commit=600
*Partition alignment si vyriesil system sam, len som skontroloval (start= 2048)
Nikdy nemam viac ako 1 G volneho miesta na disku... Kazdu chvilu mazem ~/Downloads aby sa dalo existovat dalej, notebook ma len SATA 2 a hdparm mi ukazuje ~250 MB/s
/dev/sda:
Timing cached reads: 6248 MB in 2.00 seconds = 3128.96 MB/sec
Timing buffered disk reads: 760 MB in 3.00 seconds = 253.13 MB/sec
System je svizny ako pri kupe disku. Kto chce responsivnejsi system nech si kupi SSD, mozem to kazdemu len odporucat. By ma zaujimalo ci tu popisovane problemy su specificke pre Samsungy, alebo ci aj ostatny maju taky problem s degradaciou vykonu a len ja mam stastie na dobry kus.
-
no kazdej vyrobce si to dela jinak, zrovna ten vertex4 jede bud super-rychlo v "performance mode" pokud je vic jak 50% volnych nebo pomalu v "storage mode"
rozdil je videt tu: http://www.xbitlabs.com/articles/storage/display/ocz-vertex-4-128gb-256gb_8.html
akorat na cteni to nepoznas, kdyz mas sataII; zkus zapis, ten by mel byt na hranici sataII tedy 250MB/s nebo jen 80MB/s
-
jinak jsem prestartoval a taky mi fstrim po kazdym restartu ukazuje vzdy 21.5G trimmed, podle df -h mam 17G volnyho mista
nejak jsem si toho driv nevsim, restartuju malo a mam fstrim v crontabu
takze to je jak tu majkl napsal, na zacatku proste posle trim na vsechno volne misto, ale disk si vytrimuje jen to, co bylo plne (skoda ze disk nerekne, kolik toho bylo)
dalsi volani fstrim potom posila trim jen na smazane
-
Off topic alert:
Z niektorych prispevkov mam pocit ze kupa SSD vyzaduje magiu ako installacia Gentoo par rokov doazdu.
Nevyžaduje. Mám to dosti podobně, týdně mám desítky GB zapsáno a asi jen 3GB volno a pořád frčím na maximálce SATA2. A mám zase jinou značku(obchodní značku Micronu).
-
Zdravím,
před zhruba 3 měsíci jsem pořídil nový SSD disk Samsung SSD 840 EVO - 120GB. Běží v desktopu, na desce ASUS H81M-K. Na začátku vypadaly testy výkonu perfektně, tak, jak sliboval výrobce.
sudo hdparm -tT /dev/sda1
Timing cached reads: 17826 MB in 1.99 seconds = 8945.58 MB/sec
Timing buffered disk reads: 1548 MB in 3.00 seconds = 515.63 MB/sec
Nedávno jsem zaznamenal, že systém je nějaký pomalejší a napadlo mě otestovat znovu výkon. A pohybuje se okolo 30% původních rychlostí:
Timing buffered disk reads: 456 MB in 3.01 seconds = 151.30 MB/sec
Na disku je 50% volného místa, trim aktivovaný a funguje, nic v konfiguraci se neměnilo. Systém je Ubuntu 14.04. Narazil jsem na fórum, kde řeší stejný problém: http://www.tomshardware.co.uk/answers/id-1862865/840-evo-performance-dropped.html
Nenapadá vás, jestli jde skutečně o HW problém a disk je na reklamaci? Setkali jste se s podobným chováním?
Mockrát díky.
Můžu se zeptat jak jsi to nakonec vyřešil? Přišel ke mně ten známý s úplně stejným (novým) diskem a že na něj chce nainstalovat na NTB Mint 17. A tak bych uvítal jakoukoliv ověřenou radu před tím, než mu to začnu instalovat.
Díky
-
Můžu se zeptat jak jsi to nakonec vyřešil? Přišel ke mně ten známý s úplně stejným (novým) diskem a že na něj chce nainstalovat na NTB Mint 17. A tak bych uvítal jakoukoliv ověřenou radu před tím, než mu to začnu instalovat.
Nejsem si jist, jestli jsem problém vyřešil trvale, nebo dočasně. Každopádně jsem zarovnal partition na 6MiB jak tu někdo doporučoval a nechal jsem 10GB volného místa za partition. Výkon se tím vrátil na původní hodnoty, když byl disk nový. Otázka je, jestli nezabral jen ten posun partition, který data přeházel a srovnal. Pak doplnit trim do cronu, partition mám nadále připojenou s discard. Nic víc jsem nezkoušel, ani update fw.
-
Vono je to tim, ze koukas jen na cteni. Zkus zmerit i zapis, ten by mel byt citlivy na volne misto.
-
U EVO takova hodnota naprosto odpovida, protoze se zaplnila jejich slavna "SLC", rekneme cache (trochu odlisny princip od nCache v Sandisk), ktera u 128GB varianty dela asi 3GB - to neni mnoho a vyresit to nejde, protoze se bavime o zakladni vlastnosti toho disku. Nezmenis ani v zapisu pomalejsi TLC NAND, protoze to proste nejde. Vlastnost.
Optimum, pro stabilni, nebo lepe receno konstatnejsi-predikovatelnejsi chovani v poklesu, se bere 20 - 30% jako Spare (OP Samsungy nemaji) a samozrejme to chce trimovat. Ty lepsi disky, jako treba Micron/Crucial maji jeste k TRIM vlastni GC, ktery dela svoje a M550 disponuji vyssi cache 2MB DDR na 1GB NAND. Protoze maji dost dobrou optimalizaci, par dobrych funkci (rain, power loss, ...) navic, tak jsou na tom lip, nez tyhle slavny Sh!tshungy. Po trech GB mu narve kakaovej barak i levnejsi M500, nebo stara M4.
-
Zdravím,
před zhruba 3 měsíci jsem pořídil nový SSD disk Samsung SSD 840 EVO - 120GB. Běží v desktopu, na desce ASUS H81M-K. Na začátku vypadaly testy výkonu perfektně, tak, jak sliboval výrobce.
sudo hdparm -tT /dev/sda1
Timing cached reads: 17826 MB in 1.99 seconds = 8945.58 MB/sec
Timing buffered disk reads: 1548 MB in 3.00 seconds = 515.63 MB/sec
Nedávno jsem zaznamenal, že systém je nějaký pomalejší a napadlo mě otestovat znovu výkon. A pohybuje se okolo 30% původních rychlostí:
Timing buffered disk reads: 456 MB in 3.01 seconds = 151.30 MB/sec
Na disku je 50% volného místa, trim aktivovaný a funguje, nic v konfiguraci se neměnilo. Systém je Ubuntu 14.04. Narazil jsem na fórum, kde řeší stejný problém: http://www.tomshardware.co.uk/answers/id-1862865/840-evo-performance-dropped.html
Nenapadá vás, jestli jde skutečně o HW problém a disk je na reklamaci? Setkali jste se s podobným chováním?
Mockrát díky.
http://www.zive.cz/bleskovky/ssd-samsung-840-evo-maji-chybu-pri-cteni-vyresi-to-novy-firmware/sc-4-a-175485/default.aspx
-
http://www.zive.cz/bleskovky/ssd-samsung-840-evo-maji-chybu-pri-cteni-vyresi-to-novy-firmware/sc-4-a-175485/default.aspx
Díky za link. Snad to nový firmware vyřeší. Chování by pak odpovídalo i tomu, že když jsem partition zmenšil a posunul o pár MiB dozadu. Zafungovalo to jako v diskuzi často zmiňovaná defragmentace a výkon se vrátil do normálu. Ale asi jen dočasně.
-
Takze setrnejsie riesenie by bolo posunut celu partisnu, alebo resiznut? Alebo uplne posledna moznost urobit backup a disk nim prehrat? Ci tym backupom&restore by sa nic nezlepsilo?. Joo cakat na novy firmware snad sa ho dockame velmi rychlo.
-
Este ma napada otazka. Myslite ze by bolo mozne takyto disk v sucasnom stave reklamovat. Ako ze obsahuje chybu, ktora degraduje vykon a v sucasnosti vyrobca neurobil fix?
-
Takze setrnejsie riesenie by bolo posunut celu partisnu, alebo resiznut? Alebo uplne posledna moznost urobit backup a disk nim prehrat? Ci tym backupom&restore by sa nic nezlepsilo?. Joo cakat na novy firmware snad sa ho dockame velmi rychlo.
Já posunoval kvůli zarovnání a resizoval kvůli overprovisioningu. Řekl bych, že zabralo to posunutí, protože to muselo všechna data přepsat znovu. Na windows jim nejspíš zabírá defragmentace, která s datama taky šoupe. Záloha a obnova dat bude asi taky řešení, i když dost nepraktické.
Pokud jde o reklamaci, raději bych chybu opravil. Mám to do CZC, kde jsem disk objednával, dost z ruky. Musel bych řešit jiný disk, kopírovat data sem tam... To snad raději koupit další disk a tenhle nechat na data...
-
Mna zase prave napadlo.. je z alzy. Ze bych sa pokusil o vratenie. Lebo robit workaround sam posuvanim, backupovanim a obnovou je.... jednak sa disk opotrebuje ak dostane zapisat 170GB dat. Tak ze bych ho reklamoval stym ze chcem iny kus od ineho vyrobcu ktory touto vadou preukazatelne netrpi viz crucial M550 alebo intel 530 za priplatok.
Zaloha dat a presuvanie na iny disk mi neva.
-
ty vole zapis 170GB ma smysl resit jo? proboha, to je prumerny tydenny najezd.
-
ty vole zapis 170GB ma smysl resit jo? proboha, to je prumerny tydenny najezd.
Copak 170GB, ale opakovat tu proceduru každý měsíc znovu, jen aby se výkon srovnal do udávaných hodnot...
-
No tak je to max jedno zapsani do kazde bunky, ne? ::)
Teda pokud to ma aspon trochu rozumnou logiku....
Takze nic kritickeho na wear levelling
-
No tak je to max jedno zapsani do kazde bunky, ne? ::)
Teda pokud to ma aspon trochu rozumnou logiku....
Takze nic kritickeho na wear levelling
Špatně jsem se vyjádřil. Disk snese hodně, to já bych nebyl ochoten absolvovat každý měsíc takovou proceduru :-)
-
Tenhle disk byl opravdu špatná volba.
Samsung Releases Statement on 840 EVO Performance - Another Fix Is In the Works
In October, Samsung released a tool to address a slowdown in 840 EVO Sequential Read speeds reported by a small number of users after not using their drive for an extended period of time. This tool effectively and immediately returned the drive’s performance to normal levels. We understand that some users are experiencing the slowdown again. While we continue to look into the issue, Samsung will release an updated version of the Samsung SSD Magician software in March that will include a performance restoration tool.
http://www.anandtech.com/show/8997/samsung-releases-statement-on-840-evo-performance-another-fix-is-in-the-works