Köszi! Nekem ezt a kettőt nem ismeri fel, nem tudom, hogy mi lehet, mert egyelőre működik minden. Nem akarom az összes drivert feltolni, mert nem vagyok benne biztos, hogy mind kell. Dell-nél a Win7-t javasolták, mert a Win8-al gondok vannak, lehet, hogy csak azért, mert minden drivert feltesznek az emberek.

Hátha ennyire egyszerű miért szivatjátok szegény segítségkérőket??
(akiknek lassú vagy laggol az ssd-jük)

Minek javasoljátok a SecureErase-t és a format /p -t?? elég destruktív módszerek. Ha igazad van tele a net olyan progikkal amik szoftveresen létrehoznak párszáz db 1GB-os 0-ákkal telített üres filet, ráírja az ssd-re amíg be nem telik, majd azonnyomban törli is őket.. Ezen csodaszer programok az addig lassú laggoló ssd-ket adatvesztés nélkül (akár munka közben, kockázat nélkül) gyors 500/500-as sebességre tuningolja pár perc alatt..

HA igazad van.

[ Szerkesztve ]

Már megint egybemosol több különböző (független, vagy csak lazán kötődő) dolgot és elbagatellizálod az egészet.

Utoljára még egyszer összeszedem neked a tényeket:
1: A Secure Erase SSD-nél nagyságrendekkel gyorsabb, illetve akár SSD-n, akár HDD-n alaposabb is, mint a nullákkal való teleírás, mert törli a host elől rejtett területet is (amiből arányaiban és átlagban SSD-ken sokkal több, az összkapacitás mellett sem eltörpülő méretű, akár több Gigabyte szokott lenni).
2: A Secure Erase eredménye egy kinullázott SSD (minden, a vezérlő által szabadon felülírható szektora csupa-csupa NULL, ZERO, nuku, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0.........).
3: A format tool alapvetően nem ír nullákat
4: A formázás és file létrehozás csak a filrendszer által felhasználói adatokkal teleírható területet törli, a partició és magukat a filrendszer adatokat nem törli.

Ha csinálsz egy Secure Erase-t, az ugyan az, mint ha TRIM képes OS-el törölnél az SSD-ről minden file-t (plusz még letörli azt is, amit az OS nem is lát). Csupa nulla minden szektor (0,0,0,0,0,0,0,0,0,0,0,0,0,0,0).

I.) A Secure Erase-nek HDD-knél is csak előnyei vannak a manuális végignullázással szemben, így általánosságban is javasolható, nem csak SSD-re.

II.) A formázás, DD-s nullázás, stb semmi előnnyel nem jár a Secure Erase-el szemben.

--->>> Ha semmi nem hozható fel ellene, de mellette jó néhány dolog, akkor miért ne javasolja az ember? <<<----

Az egy ettől teljesen független "probléma", hogy ahogy fogy a szabad terület, úgy lassul az írás, akár volt TRIM, akár százszor teleírod az üres területet nullákkal, akár kettévágod két partícióra és százszor leformázod az üres és tesztelt rész a telített részt békén hagyva. Ez egy másik kérdés.

Ezt miért oldaná meg az, ha egy csodaprogram (amit most feltaláltál) felirkál 1Gb-os file-okat csupa nullákkal?

Ezt már megint te találtad ki, és megint engem nézel érte hülyének!
Lassan áruld már, ha direkt sz¤patsz. Vagy legalább hívj már meg legközelebb előtte egy vacsorára, vagy valami. Ez így nem fog menni, hogy folyton meg akarsz sz¤patni, de mindig csak veszekedünk. De amúgy se foglak lesz¤pni.

[ Szerkesztve ]

TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

Na akkor mégegyszer - hátha rájösz hogy miben különbözik a véleményünk és miben nem.

Előszöris: azért értettem FSCDvel eggyet mert ő a SecureErase-t javasolta, veled pedig azért nem mert a te a formatos nullázást és/vagy a nagy nullákat tartalmazó file felírását javasoltad (ez utóbbi nem a lemez teljes felületét érintheti de ezt most nem lényeges) és feleslegesnek tartottad a TRIM-et.

Nem véletlenül nem találtál ilyen programot: megírni valóban nagyon könnyű lenne ezen programot, de a hatása semmilyen volna (=nem érne semmit) sebességnövelés szempontjából. HDD-ket pedig ne keverjük ide - az más tészta: ott a töredezettség játszik.

Másodszor: arra kerestük a megoldást hogy van aki lassúnak tartja az ssd-jét a sok használat miatt és a fenti módszerekkel erre kellene módszer hogy gyorsabb legyen a több éves használat után. Én ugyan nem láttam laggoló (több másodpercre megálló) ssd-t, és a sebesség kapcsán is mit értenek ezen hozzászólásokban lassúnak? (hogy a telepítéskori 500/500-ról leesett a sebesség 420/420-ra???)
--- Mert a másodpercekig való megállásban én nem vagyok biztos hogy az ssd okozza, az 500-ról 420-re való lassulásban pedig ez van, azaz nem tartom panaszra okot adó hibának. Persze lehet hogy az öreg 5+ éves ssd-k ilyeneket művelnek, dehát a technika fejlődik, cserélni kell ha valami kiöregszik.

Veled is sokmindenben egyetértek, sok olyanban is amit most is leírtál (újra és újra), ezért újra leírom miben NEM értünk egyet.: a (TRIM nélküli) nullázás (=format vagy üres file) gyorsító hatásában.

Részletezve: Neked a nulla az csak nulla. Ezt többször is kifejted. Sajnos ez mostanában már nem ilyen egyszerű. Azzal egyetértek hogy a flash biteket akkor lehet gyorsan írni ha 0 az értékük. DE! ez a ssd fizikai rétegére vonatkozik. A 0-kat tartalmazó file vagy a format pedig filerendszer szintjén tartalmazza a 0-kat. A kettő NEM ugyanaz. (egyik 0 =/= másik 0 val) Manapság minden ssd flash része titkosított (ezért csak 2sec a SE, ezért van hogy ATA jelszóval lezárt ssd-ből hiába veszed ki a nand IC-ket a tartalmukat nem tudod visszafejteni). Emiatt a titkosítás miatt a 00000-val teleírt file vagy a 000-at író formázás a flash fizikai rétegére már NEM 000-at ír hanem titkosított adatot amiben véletlenszerűen 1-esek is vannak. (a 3állapotú bitekről, tömörítésről szintén lehetne beszélni, de az még mélyebb rétege a valóságnak).

Tehát pont emiatt az oprendszer 000-val való írása NEM 000sítja az ssd felületét. A TRIM ahogy írtad az 0-sítja, esetleg a SE is előbb-utóbb nullásítja.Egyszerűen az oprendszer által küldött 0-ák és a fizikai rétegen a flash-on szereplő nullák közt nincs közvetlen megfeleltetés. Azokat csak a TRIM utasítással vagy talán az SE al lehetalaphelyzetbe állítani.

Remélem így már érthetőbb volt, de ennek leírására több ezer szó is szűkös lenne, és nem értelmezitek félre amit leírtam (mint ahogy eddig több helyen is).

[ Szerkesztve ]

"Előszöris: azért értettem FSCDvel eggyet mert ő a SecureErase-t javasolta, veled pedig azért nem mert a te a formatos nullázást és/vagy a nagy nullákat tartalmazó file felírását javasoltad (ez utóbbi nem a lemez teljes felületét érintheti de ezt most nem lényeges) és feleslegesnek tartottad a TRIM-et."
Bár nem nekem írtad, de úristen, miről beszélsz, ember??? Ezt most halál komolyan leírtad, miután elvileg elolvastad az előzményeket?
Tessék: [link], csak hogy idézzem az eredeti állítást janos666-tól (még a lényeget is kiemeltem neked, hátha végre hatásos lesz):
"A Secure Erase elméletben MINDEN szektort töröl, még a tartalék területet [...]
Az szerintem már csak másodlagos előny, hogy a host write számlálót sem hízlalja, az pedig a hab a tortán, hogy a kettő közül ez relatívan villám gyors. [...] A formázás alapvetően NEM írja tele nullákkal!
A zerofill az egy külön kapcsoló a format parancsnak, amit tetszőleges menetben is elvégez neked. De alapvetően csak OLVAS, nem ír. A DD valóban teleírja nullákkal, ha ezt kéred tőle, de csak a látható részt, a tartalék területet nem törli, mint a Secure Erase. Én inkább az SE-t ajánlanám."
Aztán a másikat: "Nem is mondtam semmit TRIM-ről.
Pont ezt mondtam, hogy külön kapcsoló kell még a format mögé, ha azt szeretné az ember, hogy írja is tele (már a felhasználói datokkal megtölthető terültet).
Nem, ennek semmi köze a TRIM-hez."

Érted??
Mégis hol állította, hogy a TRIM felesleges?! Az eredeti feladatot tekintve (amit gondolom még mindig nem értesz) állította, hogy a TRIM-nek jelen esetben nincs szerepe, nem általánosságban állította, hogy a TRIM felesleges lenne. Te meg azt állítod, hogy ha faltól-falig teleírja valaki 0-kkal, pl. egy live Linuxról bootolva, akkor is tök hasznos lenne a TRIM, mert biztos rettentő sok extra dolgot csinálna.

Aztán idézve Fire/SOUL/CD-t: "Szóval igen, PM-mel az Erase Disk opcióval fuss neki elsőre, arra ügyelj, hogy egy ponton felajánlja, hogy Enhanced Secure Erase-t akarsz-e, ott ne azt válaszd.
A Windows parancssorból kiadott lassú formázás 0-val írja felül az összes szektort, mint ahogy a DD is Linux alatt. Nálam a Secure Erase nem szokott használni, hogy teljesen visszanyerjem a gyári sebességeket, a lassú formázás természetesen mindig.
Más meghajtóknál persze használhat(és használni is szokott) az SE, de Samsung-oknál (470/830/840) nálam nem igazán."

És ezt érted?!
Már nem vagyok meggyőződve róla, hogy ezt felfogtad, hogy pont az ellenkezője történt, mint amiről te beszéltél, így ha már itt tartunk, ezek szerint pont kevésbé FSCD-vel értesz egyet, inkább janos666-tal. De te azért szemellenzősen hajtogatod ugyanazt!

"van aki lassúnak tartja az ssd-jét a sok használat miatt és a fenti módszerekkel erre kellene módszer hogy gyorsabb legyen a több éves használat után. Én ugyan nem láttam laggoló (több másodpercre megálló) ssd-t, és a sebesség kapcsán is mit értenek ezen hozzászólásokban lassúnak? (hogy a telepítéskori 500/500-ról leesett a sebesség 420/420-ra???)
--- Mert a másodpercekig való megállásban én nem vagyok biztos hogy az ssd okozza, az 500-ról 420-re való lassulásban pedig ez van, azaz nem tartom panaszra okot adó hibának."
Ez tényleg elképesztő. Ki beszélt MÁSODPERCEKRE megálló SSD-ről??? A nagyon minimálisan is érezhető lassulás (pl. egy 2 évvel ezelőtti állapothoz képest) szerinted definíció szerint másodperceket kell, hogy jelentsen? Még véletlenül sem elképzelhető, hogy továbbra is GYORS az eszköz, de picit mintha érződne lassulás a régi állapothoz képest? Szerinted miről beszélt FSCD is? Pontosan erről. És hol beszélt másodpercekig tartó akadásokról? Segítek, sehol! Ahogy én sem. Vagy ha ő mondja, azt elhiszed, ha más állítja, még véletlenül sem?
Simán elképzelhető, hogy egyszerűen egy OS-újratelepítés is segítene a dolgon, de azért merült fel bennem a kétely, mert korábban hasonló állapotban (ugyanennyi idő után a telepítést követően, hasonló számú programmal, amik ebben közrejátszhatnak, stb.) talán kevésbé volt érezhető HELYENKÉNT, minimálisan (NEM másodpercekre, picit, ezt az veszi csak észre, aki ismeri a saját konfigurációját) ez a kis akadás. Meg fogom próbálni a secure erase-t, újra is telepítek, mindenki happy. De maga az elméleti fejtegetés kifejezetten érdekes volt. Csak közben ne vitatkoztál volna csak azért is, mindenáron.

Miután lényegében mindent félreértettél eddig, amit csak lehetett, vagy elborította az agyad a kényszeres vitatkozási mánia, és így képtelen voltál odafigyelni, hogy itt miről beszélgettünk (és láthatóan még mindig nem érted), kicsit viccesen hat, hogy arról panaszkodsz, hogy téged értettek félre. Majd ha kicsit ráérsz, olvasd vissza a beszélgetéseket még egyszer, hátha sikerül értelmezni is a hozzászólásokat.

[ Szerkesztve ]

Sk8erPeter

Épp most írtam egy hozzászólást ami:
- összegyűjtötte az SE előnyeit a format-al szemben
- megállapította, hogy a foormat-nak nincs előnye az SE-vel szemben
- kimondta a konklúziót, hogy ha lehetséges, az SE-t érdemes használni

Most pedig azzal válaszolsz, hogy
- én a format-ot javaslom SE helyett (miután mániákus SE pártolóként tűntem fel)
- megállapítod (zárókelben), hogy túl alaposnak tartom a format-ot és/vagy más zerofill technikákat, pedig nem azok (holott ezt már számtalanszor leírtam én magam, hogy ez az egyik ok, amiért inkább SE-t javaslok helyettük)
- elmondtam már, hogy NEM tartom feleslegesnek a TRIM-et (azt mondtam el számtalanszor, hogy talán te érted félre, hogy a TRIM, vagy akár a zerofill vagy SE mit csinálnak, vagy ha külön-külön érted is a feladatköreiket, egy átfogóbb látképben már nem látod a fáktól az erdőt - bár most tovább olvasva ezt a hsz-t már fogalmam sincs, hogy mit nem értettél, mert most látszólag már érted, de mégis ugyan úgy hülye vagyok, akárhova fordul épp körülöttem a saját véleményed, most épp az én szavaim csavartad ki az ellentettjükre)

Nem találtam ilyen programot...?
Nem is kerestem, mert már eleve ismerek ilyet, pl. a Linux-os DD-t, amit használtam is már másra (de még hasonlóra is, mielőtt megismertem az SE-t). De szerintem még konkrétan az is létezik, amit te vázoltál fel, nem csak egy vagy több általánosabb célú szoftvert lehet használni hasonlóra.
De képzeld el... A TRIM-et nem támogató SSD-ket pontosan így lehet karban tartani. A saját gyártói szoftverek, O&O defrag és társaik is hasonlót csinálnak velük: kinullázzák az SSD-n is a filrendszerben logikailag már üres területeket is. (De mint már számtalanszor leírtam, a TRIM is ezt csinálja, csak valós időben és automatikusan.)

SSD-nél gyakorlatilag normális, hogy lassul, de ennek is több oka lehet:
- Pl. egy kiforratlan vagy bugos firmware-nél idővel zátonyra viszik a hajót és feladják a harcot az önkarbantartó algoritmusok (wear leveling és garbage collection, plusz ki tudja melyik gyártó mit futtat a háttérben)
- Gyakorlatilag minden SSD lassul, ahogy fogy a szabad kapacitás. Ez erősen modellfüggő (belejátszhat sok minden a felhasznált hardware elemek típusától a vezérlő hardware-ig és annak firmware-étől, illetve a konkrét modell firmware szintű paraméterezésétől az OS szintű driverekig és szoftverekig) és van egy TRIM-től független része (a TRIM-től független a kisebb mértékű, amit tovább súlyosbít, ha TRIM -vagy helyettesítő zerofill- sincs)

Én erre a problémára ezeket javasolnám így sorban:
- ellenőrizzük a BIOS/(U)EFI config beállításokat és OS drivert (AHCI/RAID)
- győződjünk meg róla, hogy működik-e a TRIM (tehát ki vannak-e nullázva a filrendszer szinten üres szektorok)
- mentsük le az SSD tartalmát és hajtsunk végre egy SE-t (esetleg, ha nagyon alaposak szeretnénk lenni, megpróbálhatjuk sorban, hogy standard, enhanced, standard; a lényeg, hogy mindig legyen lefuttatva a standard is, mert az enhanced opcionális, így nem feltétlenül működik, de elképzelhető, hogy picit alaposabb, ha mégis, és hivatalosan a standard hagy csupa nullát - bár általában gyakorlatilag az enhanced is, de azért zárjuk a kört standard-el)
- ha még mindig nem jó, akkor esetleg próbáljuk meg manuálisan feltölteni nullákkal (DD-vel és HDS-el blokkonként, ne format-al ; esetleg, ha nem tudjuk ezeket használni, akkor format /P módban), hátha (bár ennek gyakorlatilag csak akkor lesz eredménye, ha nincs TRIM)

Mindez nem számít, mert az már a vezérlő dolga, hogy mit csinál odabent.
Mindegy, hogy mivel (DD, HDS, format, filrendszer, SSD-defrag) íratod fel a nullákat, ha ő mást fog helyettük felírni.
De az SE után ilyenkor is tisztában kell lennie a vezérlőnek azzal, hogy minden terület (pillanatnyi fizikai tartalmától függetlenül) szabadon felülírható, tehát végrehajtható a NAND Erase, hisz épp most mondták neki félreérthetetlenül és halál komolyan, hogy "Most azonnal dobj el minden létező adatot, még a saját naplóidat és a szemetet is. Nem maradhat semmi! Ez parancs, nem gyakorlat!" (Lényegében ez lenne a Secure Erase). Ha ezt nem teszi meg azonnal, vagy a soron következő néhány (másod)percben (nem fut végig egy NAND Erase is titkosítás esetén a privát kulcs random újragenerálása után), akkor buta (nem tudja magát rendesen karbantartani). De akkor miért bízunk benne, hogy a TRIM után lesz NAND Erase, ha ilyen buta a vezérlő, hogy még akkor sem áll neki törölni, mikor épp azt mondták neki, hogy töröljön mindent?

A másik csavar pedig az, hogy a titkosítás a TRIM után lett divat, így esetleges néhány kivételtől eltekintve van TRIM is, ha van titkosítás. Ha pedig van TRIM, akkor nincs szükség a filrendszeren keresztül végzett zerofill-re. Ha mégis szükségünk támad valamire, akkor az SE-vel lesz még érdemes próbálkozni (nem a format-al, mert az is filrendszer szintű zerofill -> de ezt még mindig nem értem, hogy miként lettem format pártoló, mikor azzal kezdtem és mindig is azt folytattam, hogy "ezt vagy azt, csak format-ot ne").

Csak kis érdekesség, de volt SSD-d a TRIM korszak előtt? (Nekem volt, durván 32Gb került annyiba, mint ma 128Gb és egy idő után lassabb volt az írás, mint egy HDD-re, illetve igen, néha befagyott 1-2 másodpercre a Windows a jó kis Marvel vezérlővel. )

Mikor OS-en belül írsz 0-al teli fileokat, akkor utána nyilván letörlöd azokat a file-okat (különben nem lenne értelme), ilyenkor pedig a TRIM kényszerít ki egy Erase-t (ez akkor lehet érdekes, ha valamiért nem működött egy ideig a TRIM, de most már igen). Olyanról nem tudom hol beszéltünk, hogy egyidejűleg van titkosítás, de nincs TRIM.

Bár nincs értelme ennek az egész beszélgetésnek onnantól, hogy én sohasem javasoltam a format-ot SE helyett, épp ellenkezőleg, így kicsit nehéz megvédenem a nemlétező kijelentésem, hogy nem is szeretném.

[ Szerkesztve ]

TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

Most kötekszel??

írod: "Ez tényleg elképesztő. Ki beszélt MÁSODPERCEKRE megálló SSD-ről???"
FSCD (#11956) beszél róla, te is erre hivatkozol rá a (#13359)-ben. Idézem:
"már laggolást is okoz(hosszú másodpercekig "darál" az SSD és addig még az egérkurzor is beáll"

Az is elképesztő hogy mennyire nem érted mivel értek egyet és mivel nem...
janos666 (#13363) hozzászólását csak azon fentartásokkal fogadtam el amit írtam. A fenntartás a trim volt. NEM az előtte írt hozzászólásokat, nem úgy általában, hanem csak azt a konkrét hozzászólást (#13363) a FORMAT /P magyarázatokkal sebességnövelés ügyben.. illetve a 000-kat tartalmazo file létrehozással (#13370). janos666 elismerte (#13399) hogy használja a TRIM-et, nem XP-t használ(!), tehát nincs tapasztalata az XP-s SSD formázásról (trim nélkül), így tapasztalata sincs hogy ez javít-e a sebességen vagy sem.. (=bort iszik és vizet prédikál)

Te is leírod mindazt amivel -szerinted- nem értek eggyet, de valójában egyetértek vele, így csak a hangulatot fokoztad az ismételgetéssel..

Természetesen a TRIM-ről nem általában beszéltem hanem a FORMAT /P vagy a DD használata során..

[ Szerkesztve ]

hopsz, majdnem elszalasztottam a hozzászólásod..

Így már minden OK, nincs véleménykülönbség köztünk.
Felejtsük el a FORMAT /P és DD és a nullfill módszereket hamár egyikünk se javasolta..
Elnézést a kölcsönös félreértésért.

+ (#13424) : Hát ez király, kiderült, hogy pont az történt, amit leírtam, mégpedig kiderült, hogy igazából senkivel nincs vitád, csak mindeddig nem sikerült felfognod, hogy miről beszélgettünk így hárman. De azért a biztonság kedvéért párszor néhány gyakorlati tanácsot hülyeségnek minősítettél, hogy nehogy kimaradj az egészből. Hasznos volt. Ja, nem.

Sk8erPeter

NE kötekedj! Kiderülne hogy te nemcsak a másodpercekre nem emlékszel..

Tyűha, ez már annyira színvonal alatti és óvodás reakció volt, hogy asszem ilyen szintre már tényleg nem érdemes lesüllyedni. A szövegértelmezési és önértékelési gondjaiddal nehéz mit kezdeni, úgyhogy innentől lehetőleg fejezzük is be a szúrkálódást, nem kéne, hogy moderátornak kelljen rendet tennie. Inkább térjünk vissza a szakmai vonalhoz, az oda-vissza reagálást meg hagyjuk.

Sk8erPeter

egy darab SATA 2 csatlakozóval - Hülye kérdés, de tápcsatlakozót azért kapott mellette?

Organic Maps - ingyenes, offline navi iOS-re és Androidra.

Milyen meglepő, hogy tápellátás nélkül nem működik...

Sk8erPeter