Samsung EVO 840 SSD tapasztalatok?

Gondolkodom egy Samsung EVO 840 SSD beszerzésén, de előtte szeretnék némi személyes tapasztalatot olvasni róla.

Erről a termékkódról lenne szó: MZ-7TE120BW, ami elméletileg gyors, TLC és hardveres titkosítást is tud végezni (AES-256), ha mindez igaz.

Próbált valaki ilyet vagy hasonlót? Mi kell ahhoz, hogy a hardveres titkosítás működjön? (pl. alaplapon ilyen-olyan BIOS, amiben van ilyen-olyan beállítási lehetőség stb.)

Hozzászólások

Mi sima 840-est (ami szinten TLC) telepitettunk megfigyelo rendszerbe egy hajora es kopogjam le 1 eve uzemel hibatlanul. Allando felvetel van, de igy is elvileg birnia kell legalabb 5 evet. Ennyi idonkent egy merevlemezt is illik lecserelni.

Sok tapasztalat nem lehet ezekkel, mert elegge ujdonsag a TLC a piacon.

Miert ne lenne?
Folyamatos linearis ujrairas. A wear levelingnek nincs is dolga. Sokkal rosszabb neki a random iras, amit vagy el tud osztani vagy nem.

A TLC tobb mint 1000 ciklust tud. Ha napi 50 GB-ot veszunk egy 250 GB-os lemezen, akkor 5 naponta van egy ciklus. Vagyis 5000 napot megy kb mire meghal. Ez ugye 13 ev, ami boven tobb mint az altalunk tervezett 5 eves csere.

Raadasul a tengeri viharok, razkodasok sincsenek ra hatassal (ez volt a fo ok az SSD mellett). Arrol ne is beszeljunk, hogy biztonsagi okokbol napelemek toltik az akkut es igy a fogyasztas sem mellekes.

A statisztika nem mindig valóságos. Sok előnye van tény, de viszont a 24/7-es folyamatos üzem... nem hiszem, hogy az átlag notebook-ba tervezett SSD-ket ekkora igénybevételre tervezik. Simán elromlik az elektronikája, és kész.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

Tökéletes AV felhasználásra. Semmi gond nincs velük, rengeteg broadcast rögzítőben is ssd van. Jó választás volt a hajóra is...

----------------------------------------------------------------------------------------------------
Hármas........alá............kettes.........................egyest írtam be.

Többi notiba került EVO a gyárban és eddig jól mennek. Teljesen sima juzerek egy Win7-ekkel. Általában 6400/6410-es DELL Latitude-ök és AHCI-vel.

Szia!

Egy fél éve van meg az SSD, eddig normálisan ment. De ez asztali gép, ezen van a fő rendszerem, torrent nem megy rá, és arch linux-szal használom.
Egyelőre nincs panasz, teszi a dolgát.


SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 1034
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 329
177 Wear_Leveling_Count 0x0013 099 099 000 Pre-fail Always - 1
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always - 0
181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0
182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0
183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0032 074 059 000 Old_age Always - 26
195 Hardware_ECC_Recovered 0x001a 200 200 000 Old_age Always - 0
199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0
235 Unknown_Attribute 0x0012 099 099 000 Old_age Always - 8
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 709216890

Üdv!

pont most vettem belőle két darabot, raid1-be. ami a tapasztalat igy elsőre:
gyorsaság (sata3-on van mindkettő) irás 230-240M olvasás 530-540M

sajna mdadm-val létrehozott raid1 olvasása pont ugyanannyi mint 1ssd-é, ezt még megcsekkolom miért lehet, de már nem várok csodákat amióta a 840prok meg teljesen használhatatlanok mdadm raid1ben:\

borzasztó teljesitményt hoz.

igy hozom létre tök simán:
mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1

és pl irásra ~10-20-30M olvasásra sincs a toppon.. elég sok helyen olvastam ugyanezt a problémát, firmware némelyeknek segitett, de nálam a legújabb van rajta, szóval ezzel sem tudtam mókolni. egy magában nagyon szép teljesitményt hoz, most pl ki is vettem raidből, mert szétment tőle a drbd hogy ilyen lassú volt

Ezt jo tudni! En azt hittem, hogy SSD-nel mar nem szamit annyira a firmware RAID eseten, mint normal merevlemeznel.

En ettol fuggetlenul meg mindig tartom azt, hogy inkabb tobb teljesen kulonbozo lemez legyen a RAID-ben, mert az azonos tipusok eseten a hibak nem fuggetlenek. Azaz azonos hasznalat alatt nagyobb valoszinusege van meghalni egyszerre ezeknek a lemezeknek. Persze ha a sebesseg fontosabb, mint a 100%-os uzem, akkor ez nem all. Valamelyik nyilt forrasu projekt alatt is - ha jol emlekszem - egyszerre haltak meg a lemezek (es persze backup sem volt).

Meg 2010 korul volt az akkor uj Kingston V100-as szerianak egy firmware hibaja, amitol elerhetetlenek lettek. Mivel a hiba oka egy mezei overflow volt, az egyidoben beepitett (gyk. RAID) SSD-k nagyjabol egy idoben haltak el. De ezt is csak onnan tudom, hogy konkretan beszoptam egy ilyennel, illetve csak azert emlitem, hogy bar nagyon ritka, de tavolrol sem elmeleti valoszinusegu a dolog.

Szerk: 2011 eleje volt az valojaban. http://forums.hexus.net/storage/201030-kingston-ssd-v100-firmware-updat…

A hardveres AES-256 encryption/titkosítás működik valakinél? Van ennek valamilyen különleges feltétele? Az op. rendszer betöltődése előtti dologról van szó, tehát gondolom nem független a BIOS beállítási lehetőségeitől sem.

Hogy működik ez a gyakorlatban?

Annyi információt sikerült összeszedni, hogy az EVO 840-hez még nem volt megfelelő firmware amikor kiadták, így akkor még a titkosítás nem volt támogatott. Azt nem teljesen tudtam összerakni, hogy bizonyos rendszereket nem támogatott (pl. MS Win hardveres titkosítás támogatása (ezek a szavak egymás után máris röhögőgörcsöt okoztak nálam)) vagy úgy en bloc nem ment rajta a hardveres titkosítás.

Minden esetre a legújabb firmware állítólag megoldotta ezt a hiányosságot.

A BIOS-ban kell lennie HDD jelszavas védelemnek, ezzel lehet aktiválni az EVO 840 jelszavas védelmét is. Az adatok amúgy is kódolva vannak a meghajtón, csak a dekódoláshoz szükséges kulcs a meghajtón is fel van tüntetve, így messzire nem szaladunk, ha HDD jelszóvédelem nélküli BIOSunk van (laptopokban fordul elő leginkább, ha jól tudom).

A vigaszom annyi, hogy a felhívott forgalmazóknak gőzük sincs róla, hogy hogyan kellene működnie az EVO 840 említett AES-256 titkosításának.

Kollégám ilyet nyúz problémamentesen két hónapja, Vertex2-mhöz képest kib@aszott gyors. :)

En Seagate 600 PRO SSD 480GB vagy Intel DC S3500 480GB SSD-n gondolkozok, van valakinek tapasztalalta veluk ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Hi,

Most rendeltem egy ilyet.

Kell még egyáltalán az a kb. 10%-os partícionálatlan terület, vagy az csak a korai SSD-k esetében volt szükséges?

Hátha még nem volt:

Maximize SSD Lifetime and Performance With Over-Provisioning

Over-Provisioning (OP), the practice of allocating a specific, permanent amount of free space on an SSD, is a widely-used method for improving both SSD Performance and Endurance. Historically, Samsung has not implemented mandatory OP on any of its SSDs. With the introduction of the 840 Series and the reality of increasingly complex NAND fabrication processes, however, Samsung has chosen to implement a minimum amount of OP in its mainstream drives (the 840 PRO will not feature mandatory OP).

[...]

As NAND process technology advances, the chips themselves become increasingly smaller. As they shrink, the chips also become less reliable at holding data. There are a number of ways to mitigate this problem, including using Error- Correcting Code (ECC). As explained above, any time we give the controller more work to do, it requires more room on its “work bench” to do it efficiently.
The 840 Series represents the first consumer SSD to implement 3-bit/cell MLC (also called TLC) technology. This technology, as its name suggests, stores 3-bits of data per cell, as opposed to the 2-bits per cell that today’s more common Multi-Level Cell (MLC) NAND holds. Because, as just mentioned above, the size of the chips themselves is also shrinking, in effect we are squeezing even more information into a smaller space.
This is nothing a good firmware algorithm can’t handle, however. Samsung’s 3-bit/cell MLC-based SSD 840 Series, equipped with mandatory OP, will still far outlast the useful life of the hardware it powers.

--
trey @ gépház

mióta megjelent több száz dbot adtunk el/építettünk be, kisebb szerverekbe is és eddig még egy se adta be a kulcsot

Most fogok egy 250 GB-set venni a gépembe, eddig csak jókat olvastam róla.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
Szerinted…

Nekem 50 MB/s az olvasasi sebessege. Ez normalis?

Parameterek:
120 gigas verzio, SATA2 porton.
- Elejen 80 gigas particio, TRIM nelkul hasznalva, tele toltve (titkositott filerendszer (az olvasasi sebesseg a nyers adatra vonatkozik, nincs benne a titkositassal molyolas)).
- Vegen 40 giganyi ures hely, soha nem volt erintve sem.

A 80 gigat olvassa 50-60 Mbyte/s sebesseggel, a 40 giga erintetelen reszt 260 MB/sec korul, ez gondolom a SATA2 limitje.

Meresek hdparm -t /dev/sda /dev/sda3 illetve dd if=sda(3) of=devnull bs=64M count=10 modszerrel.

A hasznalatba vetel utan nem sokkal (kb. egy het) mertem eloszor, mar akkor lassu volt. (A particios tablat es a titkositott particiot raddztem egy masik eszkozrol, nem friss telepites.)

Ha arra erted, akkor a flash memoria maga nyilvan aktiv hasznalat alatt van a kontroller altal, ugy ertettem hogy kivulrol az SSD-tol, mint blokk eszkoztol nem kertem a hatso 40 gigara irasi muveletet.

Ha meg arra gondolsz, hogy manapsag felesleges ennyi helyet fenntartani, hogy tudjon mivel gazdalkodni, akkor egyetertek, de mint irtam is nem friss telepites volt, dd-vel koltoztem egy masik eszkozrol. Majd novelek, ha lesz ido/kedv.

Szétoffolomatopicot!!!négy!

Az általad említett dd-s mérés egy SATA 3-as Corsairon:

dd if=/dev/sda1 of=/dev/null bs=64M count=10
10+0 beolvasott rekord
10+0 kiírt rekord
671088640 bájt (671 MB) másolva, 0,748406 mp, 897 MB/s

Ha a Chrome pörög közben...

671088640 bájt (671 MB) másolva, 1,31008 mp, 512 MB/s

Bár lehet valami cache van a dologban...

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

Még mindig úgy van, hog az EVO otthoni felhasználásra, a PRO pedig szerverekbe szánt?

Application Client PCs, Enterprise Computing 1 (1:For enterprise PC usage(e.g.servers), a minimum of 6.7% over-provisioning(OP) is recommended and can be set through Magician)

http://www.samsung.com/hu/consumer/printers-monitors-peripherals/ssd-ca… - innen.

Más kérdés, hogy a mellékelt marketing dumától az ember zsebében kinyílik a bicska. Teli maximális, csúcsteljesítmény etc. jelzőkkel, miközben nem mondanak semmit. :DDD
(nem tudom, milyen lehet, de ezek alapján én messzebbre kerülném, mint a tv shopos szemeteket)

Pro-t inkább a felsőkategóriás és erősebb felhasználású desktop/munkaállomás vonalra szánják, nem szerverbe, de ettől még enterprise jellegű. Van külön szerver vonaluk is PM kezdettel, illetve a 845DC mosmá: http://www.storagereview.com/samsung_ssd_845dc_evo_review Van még SM-es is: http://www.storagereview.com/samsung_sm843_enterprise_ssd_review

Aktuális hír: http://www.storagereview.com/samsung_ssd_850_pro_review

A Samsung gyári ajánlása az, hogy futtasd a (természetesen csak windowsos) Samsung Magician Software-t, majd az megmondja, hogy van-e beállítva OP terület, vagy ha nincs, akkor csinál. Nyilvánvaló, hogy aki Linuxot használ, az is meg tudja oldani azt, amit a Magician csinál (kb. 10%-nyi nem particionált terület meghagyása az SSD végén).

Itt:

Samsung 840 EVO over-provisioning

--
trey @ gépház

Én nem tudom, hogy odavaló-e. Csak a véleményemnek adtam hangot: amit ilyen ordenáré reklámmal kell eladni, az finoman szólva gyanús ;)
Egyébként SOHO környezetben még elfogadható lehet akár egy LAN-t kiszolgáló szerverbe is, mert nincs annyira rossz híre.
De komoly szerverbe, nagy igénybevételnek kitéve... oda nem tenném az eddig olvasottak alapján.

Pár hónapja vettem egy MZ-7TE500BW-t a laptopomba.
Az a bajom vele, hogy folyamatosan csökken az olvasási sebesség, hdparm-mal mérem.
Az elején 500MB+ volt, majd folyamatosan csökkent ~110MB/sec-re.

Miután megcsináltam egy cella törlést ( https://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing ), az olvasási sebesség visszaállt az eredetire, de megint úgy látom, hogy folyamatosan csökken (most már 450MB körül van).

Mielőtt valaki kérdezné:
- discard természetesen be van állítva a fstab-ban, de próbáltam periodikus fstrim-mel is (ilyenkor nem volt discard)
- partition alignment rendben van (blockdev --getalignoff 0-t ír ki)
- kernel 3.15, nem hiszem, hogy ezzel lenne a gond
- a free space minden partición 50% fölött van

Valakinek ötlete, hasonló tapasztalata?