Hirdetés
-
SGF24 - Remekül fest a Phantom Blade Zero
gp A Summer Game Fest utolsó játéka nem más volt mint a PC-re és PS5-re készülő játék, amelyhez még mindig nem kaptunk megjelenési dátumot.
-
Pénzt akar a WhatsAppból a Meta, az AI majd segít
it Új AI-eszközöket kapnak a cégnek, a Meta célja, hogy több bevételt szedjen ki a WhatsAppból.
-
Retro Kocka Kuckó 2024
lo Megint eltelt egy esztendő, ezért mögyünk retrokockulni Vásárhelyre! Gyere velünk gyereknapon!
-
PROHARDVER!
Ide várunk:
- minden saját tapasztalatot/tesztet, észrevételt a már megvett, és használatban lévő SSD-vel kapcsolatban, illetve mindenféle, megbízható forrásból való cikket/tesztet/érdekességet.
Új hozzászólás Aktív témák
-
MiZY
tag
Idevag az Arch Linux wiki oldala
AHCI fronton, ha bekapcsolod a BIOSban, akkor menni fog. Fstabba a trimet kell berakni a megadott particiohoz a discard csatolasi opcioval, illetve, hogy ne birizgalja mindig a fajlok eleresi idejet. Elvileg semmi mas trukk nem kell!
[ Szerkesztve ]
-
#1015
Fire/SOUL/CD
félisten
Kinder
#1012
Egy másik alaplapra kötöd (nem USB portra) és ha az látja, akkor lementhető az adat, pl egy Linux Live CD/Pendrive segítségével(pl Ubuntu is indítható így telepítés nélkül)
Ha gariba megy vissza, akkor a FW frissítést ne említsd meg (USB-n meg nem frissítünk FW-t, nehogy az új meghajtónál is ilyet elkövess)
UI:
1. A Hard DIsk Sentinel rendesen kezeli az SSD-ket, csak a legfrisebb változatot kell használni (USB-n nem lehet TRIM-et lekérni, azért a 80%)
2.Ha egy másik alaplapra kötve rendesen megy, akkor úgysem fogják kicserélni, csak ha nagy szerencséd van és nem próbálják ki az SSD-t garanciáztatás előtt, amire kicsi az esély. Épp ezért mindenképp próbáld ki az SSD-t egy másik konfigban, ellenkező eetben hiába viszed vissza, csak annyit fogsz elérni, hogy vissza fogják adni, de a felmerülő plusz költségeket is ki kell fizetned.Mindenki tudja, hogy bizonyos dolgokat nem lehet megvalósítani, mígnem jön valaki, aki erről nem tud, és megvalósítja. (Albert Einstein)
-
Jester01
veterán
válasz
Sturlung
#1315
üzenetére
1. Igen, csak "felszíni" felosztás. Amíg fizikailag van üres blokk addig mindegy, hogy partícionálva hogy van és hol mennyi az üres.
2. a 60-70% erős túlzás. 80-90% bőven jó, főleg ha tömörítős a vezérlő.
2.1. igen
2.2. nem
2.3. nem
3. Ha az amúgy üres blokkokat is visszaklónoztad vagy nem ment a TRIM akkor igen (ez utóbbi linuxon a discard mount kapcsoló egyébként).
MOD: illetve ha totál megtöltöd egy fájllal amit aztán működő TRIM mellett törölsz, az is jó. Így nem veszik el adat.[ Szerkesztve ]
Jester
-
Jester01
veterán
válasz
Sturlung
#1820
üzenetére
Ez szerintem nem működhet.
Hiszen a TRIM parancs a fizikailag felhasznált blokkokra kerül kiadásra ha pedig sparse fájlt csinálsz az nem használ fel blokkokat tehát nem is fog TRIM parancsot küldeni. Hacsak microsoft nem alkotott valami marhaságot megint. Linuxon a sparse fájl nem foglal helyet, simán csinálhatok terabyte méretűt is.$ dd if=/dev/zero of=test.bin bs=1M seek=1M count=0
0+0 records in
0+0 records out
0 bytes (0 B) copied, 2.3913e-05 s, 0.0 kB/s
$ du -h test.bin
0 test.bin
$ du -h --apparent-size test.bin
1.0T test.binHa rendes fájllal írod tele akkor lehet értelme, már ha amúgy nem bízol az operációs rendszerben. Csak akkor meg 'kopik'.
Jester
-
#4068
Fire/SOUL/CD
félisten
ScomComputer
#4067
válasz
ScomComputer
#4067
üzenetére
Valami nem lekezelt partíció attribútum van a partíción. Légy szíves küldj riportot és majd megnézem és javítom.
Nixon18
Nem fut Linux alatt a progi. Linux meghatározott kernel verzió felett támogatja a TRIM-t ill. bizonyos fájlrendszerek esetén külön be kell kapcsolni. A Linux disztrók is már rég óta (2008 tájéka óta talán) támogatják, szóval ez nem gond (EXT4 meg alap ugyebár)Mindenki tudja, hogy bizonyos dolgokat nem lehet megvalósítani, mígnem jön valaki, aki erről nem tud, és megvalósítja. (Albert Einstein)
-
Qru
MODERÁTOR
válasz
gyulank
#5195
üzenetére
Mehet NTFS-re és nem kell állítani, a W7/8 telepítő formázója a megfelelő méretezéssel dolgozik alapból.
Formázottan célszerű a 10%-ot tartani valóban.
Rakhatod hdd-re de akkor pont az ssd nyújtotta sebesség előnyétől fosztod meg magad. Nem hímes tojás, használd, azért veszed. Ha mindenképpen extrém módon kímélnéd akkor már inkább ramdrive-ba irányítsd a böngésző cache-ét.
Linuxban nem vok járatos, arra majd más válaszol. De ha nem, akkor sincs gáz, mert van megfeleő progi, ami helyettesíti a trim-et.
#nincsbennetarcsi
-
#5864
Fire/SOUL/CD
félisten
brugo
#5862
Bizonyos kernel verzió felett már támogatott a TRIM, ez gyakorlatban szinte minden modern Linux-t lefed, csak egyes disztróknál be kell kapcsolni a telepítést követően, pl Debian/Ubuntu alapú disztróknál: [link]
Természetesen a telepítők particionáláskor már a helyes partíció eltolásról is gondoskodnak, bár a SWAP partíció kezdetét el szokták kettyinteni.
Alapvetően nem öregszik jobban egy SSD Linux alatt sem...ÁdiBá - Teljesen értelmetlen RAID-ben használni 2 SSD-t rendszermeghajtónak, még ha egyformák lennének, akkor sem.
A lassabb valamelyest visszafogná a gyorsabbat, ez RAID üzemmódonként különböző mértékű lehet, de ebből a user semmit nem venne észre természetesen. Olvasnivaló.[ Szerkesztve ]
Mindenki tudja, hogy bizonyos dolgokat nem lehet megvalósítani, mígnem jön valaki, aki erről nem tud, és megvalósítja. (Albert Einstein)
-
#6461
Stonerice
őstag
Daszkalosz19
#6459
Stonerice
őstag
válasz
Daszkalosz19
#6459
üzenetére
Szia!
Megpróbálhatod linux alapú OS-ről, ami leis tölthető az OCZ oldaláról, vagy pedig ilyen win 7 ultimate live.
Ezt szoktam pendrive-ra tenni, bebootolok róla, és frissítem windows os exe-vel. Igényelhet netbeállíítást..
Egyébként ne frissíts FW-t szerintem mert írják egy páran, hogy nem működik a TRIM a 2.25-el
Nekem is nemrég szállt el..előző fw-vel nemvolt még ilyen nekem.Nekem is lenne egy kérdésem a többiek felé!
Olvastam, hogy visszalehet tenni a régi fw-t linux alól. leis töltöttem a 2.15-öt. Segítene valaki?
ITT próbálkoztak a 2.22 visszatétellel.[ Szerkesztve ]
Pénz beszél, kutya utal! Aktuális főkomponenseim: 5600X / Msi B450 Gaming Plus Max / 16GB 3733 cl16 / Sapphire Nitro Rx480
-
Húha.
Áttoltam mindent a 840 Pro 128Gb-ról DD-vel egy laptopwinyóra, és elkezdtem szekvenciálisan teleíratni nullákkal az SSD-t Hard Disk Sentinel felületteszttel. Az eredmény eddig borzasztó, 22 és 40 Mb/s közt ingadozik az írási sebesség. Szóval átlagban is lassú, ráadásul azt sem igazán értem, hogy miért ingadozik ennyire, hogy mozaikos a HDS szektortérképe.
Nem tudom, hogy a zerofill-től (ami saccra még legalább egy óra!) vagy majd egy Linux hdparm-os erase-től magához tér-e (és esetleg a TRIM-el volt gond, vagy csak annyiból bugos az SSD vezérlése, hogy idővel "betömődik", mint a régi Intel-ek), vagy ekkora átb@szás volt ez az SSD, hogy potom 12Tb felírása és ~111 üzemóra után így lelassul az írási sebessége (fixen és örökre).
De az is biztos, hogy bármi az igazság, egy prémium terméktől sehogy sem szép teljesítmény, még akkor sem, ha valamivel indokolható és akár valamennyi user error is van benne valahol. Nem egyszerűen elmarad a hirdetett, és kezdeti mért eredményektől, hanem gyakorlatilag egy nagyságrendet lassult a szekvenciális írás.
Én meg még azt hittem ez kiszámíthatóbb és hosszabb távon megbízhatóbb lesz, mint az OCZ Vector.
[ 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."
-
Mezey Lipót
tag
válasz
Fire/SOUL/CD
#8735
üzenetére
Köszönöm a választ, akkor nem aggódom...
Linux alatt is belóttem a TRIM-et, - mivel itt a rendszert lassító jellege miatt nem célszerű valós időben TRIM-elni - napi időzítésű automatikus ütemezést állítottam be.asdf_: Én is ilyen értékeket szeretnék rövidesen látni a sajátomon.
Rendes vagyok. Segítek másoknak hogy legyen egy igazán sz@r napjuk.
-
#8772
Mezey Lipót
tag
andaman
#8769
Mezey Lipót
tag
válasz
andaman
#8769
üzenetére
Én most telepítettem W7-et és Linuxot és minden OK, gyors lett a gép mint a szél.
Windows7:
Telepítés:
AHCI mód beállítása(fontos) a BIOS-ban (még az oprendszer telepítése előtt!).
A W7 telepítő lemezzel kell partícionálni és a hagyni kell annyi particionálatlan területet, hogy az össz terület 15%-a lefoglalatlan maradjon(120GB-os SSD esetén ez kb 8GB, 128GB-osnál ennek a duplája).
Telepítés a kiválasztott partícióra.
Ellenőrzés:
Beállítások, sebesség és TRIM használat ellenőrzése az ITT található programokkal és a leírás alapján.
Fontos: Windows 7 felismeri hogy SSD-re került, tehát a töredezettség-menetesítést, a prefetch-et és a superfetch-et(előtöltés) inaktiválja, tehát ezeket nem kell módosítani. Ellenőrizni lehet.
Érdemes(hely és az SSD kímélése végett): lapozófájl(pagefile.sys) használatot kikapcsolni, vagy egy fix kisméretű lapozófájl méretet beállítani. Ha nincs szükség a gép hibernálására, érdemes kikapcsolni(asztali gépeknél a W7 alapértelezetten ki szokta kapcsolni.
Linux:
Telepítés a kiválaszott partícióra, majd időzített TRIM beállítása napi ütemezéssel.A lényeg kb ennyi.
Ha minden kész, a tesztprogramok(SSDOK és CrystalDiskMark eredményeinek a képernyőképeit ide belinkelve az okosok majd megmondják a tutit.
Rendes vagyok. Segítek másoknak hogy legyen egy igazán sz@r napjuk.
-
qltsar
addikt
Sziasztok!
Jelenleg egy Kingston v300-as van a gépben, két(három) particióra osztva ([350MB] 70GB NTFS - 40GB EXT4). A rendszereim klónozva lettek az előző HDD-kről, egy kis trükközgetés volt az MBR-rel, és a GRUB újrahúzásával de végül minden stimmel.
A kérdésem az lenne, hogy Linux rendszerrel kinek milyen tapasztalata van SSD használatával? Pontosabban a TRIM-re gondolok. Az fstrim-et beállítottam 13.10-es Ubi alatt, és ha minden igaz 14.04-ben ez már alapértelmezett lesz. Vajon meg lehet nézni valahogy, hogy tényleg működik e ilyen formában a TRIM?
Köszönöm
![ Szerkesztve ]
-
válasz
ubyegon2
#12948
üzenetére
Mi lehetne vele a gond?
Az OS-nek alapvetően egyáltalán nem kell foglalkoznia vele, hogy HDD vagy SSD, ugyan olyan IDE vagy AHCI SATA eszköz mindkettő.
Persze a TRIM és esetleges auto-defrag vagy akár különböző filerendszer konfigurációk miatt nem árt, ha különbséget tud tenni, de ezen a téren a Linux vezet a Windows-al szemben. Itt több különböző, akár kifejezetten flash memória alapú eszközökre optimalizált filerendszerek közül is válogathatsz, míg a Windows csak NTFS-re hajlandó települni, ami ha nem is rossz, de nem is kimondottan ideális az SSD-knek (FAT32-re már nem, ReFS-re még nem telepíthető mostanában a Windows, de amúgy sem javasolnám egyiket sem, illetve a ReFS is inkább nagy méretű HDD-kre lesz optimalizálva, mintsem flash alapú eszközökre).
A mostanában alapértelmezett EXT4-el is lehet TRIM-elni az üres területet, de ha most telepítenék egy friss rendszert és nem lenne fontos, hogy Windows alatt is olvashatóvá lehessen tenni az adatokat, akkor kipróbálnám az F2FS-t (nem feltétlenül használnám 24/7, mert még elég fiatal, de letesztelném és akár úgy is hagynám). Ezt javarészt Samsung programozók írják a Linux kernelhez, direkt NAND flash eszközökhöz (elsősorban inkább a saját Androidos telefonjaikra gondolhattak, de SSD-khez is ugyan úgy passzol). A telefonomon már ezt használom egy ideje.
[ 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."
-
válasz
ubyegon2
#13318
üzenetére
Persze, egy régi SATA2-es SSD is látványosan lever minden HDD-t, mint rendszerlemez, még a Raptor-okat is, mert random olvasásban mindenképp gyorsabb (random írásban néha lehet lomha, ha nagyon telepakolod és főleg, ha nincs megoldva a filrendszer szinten üres blokkok üresjárati törlése, auto TRIM-el vagy másképp).
Igazából én sem használom.
Az asztali gépen és laptopon is Win8 fut (előbbin videojáték és CAD, utóbbin HCFR szoftver miatt).
Volt itthon egy gép, amin Gentoo dolgozott pár hónapig, mert számottevően jobban teljesített egy célra konfigurált Linux kernellel, mint Win8-al (egy ideje már nem futott, ma már elvitték belőle az ATX tápot és a RAM-ot is, szóval lassan akár törölhetem is a rendszert).
Először SSD-re telepítettem a rendszert (hátha hamarabb végez, bár a CPU-t nyúzta jobban a GCC), de aztán egy lomha 2.5" HDD-re klónoztam át és arról ment az a gép (pazarlás lett volna bármi más, nem volt szükség háttértár I/O teljesítményre).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."
-
ubyegon2
nagyúr
válasz
janos666
#13319
üzenetére
random írásban néha lehet lomha, ha nagyon telepakolod és főleg, ha nincs megoldva a filrendszer szinten üres blokkok üresjárati törlése, auto TRIM-el vagy másképp
Köszi, úgy látom lesz mire ráfeküdnöm, ha megveszem, mert ezek elég kínaiul hangzanak.
A TRIM- ről annyit olvastam, hogy az újabb Linux változatok jó része már kezeli, bármit is jelent ez.
SSD- re pár Linux disztrót teszek meg a FF- ot, a torrentkliens meg egyéb elfér a Blacken.Pont ezekre a spéci programokra gondoltam, amiket használsz, ezek miatt persze, hogy kell a Win, de egy mezei usernek nem túl fiatal gépen, amin csak böngészik, médiázik, etc. bűn Win 7- et, 8- at használni. Önmagában az, hogy nem kell rá vírusírtó és tűzfal, ami zabálja a rendszerforrásokat, már sokkal gyorsabbá teszi a Linuxot. Az XP kampózása elég sok embert indított egyébként a Linux felé és mindenki kisebb csodaként éli meg a változást, ahogy a kezdők topicjában olvasom.
Mindenesetre köszönöm a segítséget, de ha meglesz az SSD, biztosan lesznek még érdekes kérdéseim.
Samsung 860 EVO 1TB SSD 30eft 6,7TB írás még garis
-
válasz
Doky586
#13365
üzenetére
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. A TRIM akkor dolgozik, ha törölsz valamit az SSD-ről, nem akkor, amikor írsz rá. A Secure Erase már inkább egyfajta TRIM, de annak Secure Erase a neve, nem TRIM, és mindent töröl, nem csak a filrendszer szinten üres AU-khoz tartozó sztektorokat.
Win XP format -> pont erről beszéltem, de ez nem az XP baja, a format tool ilyen, viszont van olyan kapcsolója, amivel azt csinálja, amit ő szeretne (legalább is frisebb Windows-okkal települő format tool, az XP-é még nem tudom, hogy ismeri-e a /P kapcsolót).
Szerintem aktív, mert ugyan olyan AHCI vagy RAID drivert tölt be, de a TRIM itt és ilyen szempontból továbbra is teljesen irreleváns.
Az SRCD-t nem ismerem, de ha Windows Recovery alapú, akkor ugyan az vonatkozik rá, mint a Windows Recovery-re és a Windows telepítési környezetre (ugyan az az AHCI driver fut, ha nem piszkálták meg). Ha Linux alapú, akkor passz, de ha friss a kernel, akkor ott is menni kellene a TRIM-nek (aminek továbbra is abszolút semmi köze az alapértelmezett paraméterekkel végzett formázáshoz, vagy ugyan így a DD-vel történő zerofill-hez, vagy hasonlóhoz).
Szerintem félreérted, hogy mit csinál a TRIM, és talán azt is, hogy ő mit szeretne csinálni.
A másik félreértés (annál, akinek először reagáltam) pedig valószínűleg az, hogy ha minden egyes olyan terülten megtörénik a törlés (NAND Erase), ami törölhető (szoktak az ilyen meghajtók, akár HDD, akár SSD saját adatokat is tárolni ugyan ott, ahol a felhazsnálói adatokat, tehát pl. ugyan azon a HDD korongon, vagy SSD-nél a NAND területen, ahova mi is írhatunk, nem egy fizikailag is elszeparált területen tárolnak mindent, mint pl. egy külön kis flash memória ROM-ként), akkor már semmi nem változik érdemben attól, ha a SATA interfészen át is teleíratja valaki csupa nullákkal (ha okos a vezérlő, akkor nem is hajt végre a NAND-on Program lépést, bár amelyik nem tömörít, az talán mégis megteszi ahelyett, hogy mondjuk inkább olvasna ilyenkor ön-ellenőrzésképp, a tömörítős meg csak pihizik).
[ 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."
-
#13393
Sk8erPeter
nagyúr
Fire/SOUL/CD
#13371
Sk8erPeter
nagyúr
válasz
Fire/SOUL/CD
#13371
üzenetére
(#13371) Fire/SOUL/CD, illetve (#13360), (#13363), (#13366), (#13367), (#13370) janos666:
Köszi szépen a válaszaitokat, nagyon hasznosak és érdekesek voltak! (Én is bocsi, hogy csak most tudok érdemben reagálni, mostanra volt időm mindent elolvasni, amiket írtatok.)"Szóval igen, PQ-val az Erase Disk opcióval fuss neki elsőre"
Bevallom, a PQ rövidítést nem teljesen értettem, de gondolom a Parted Magicre gondoltál; konkrétan gondolom erről van szó, amit korábban linkeltél, igazából pont így terveztem:
1. boot Parted Magicről (még megvan a pmagic_2013_08_01.iso, ami még ingyenes volt)
2. System Tools > Erase disk > "Internal Secure Erase command writes zeroes to entire data area" > ezután az eszköz kiválasztása > NULL (mivel nem akarok jelszót beállítani) > majd ha az Enhanced Secure Erase opciót felajánlja, a No-ra megyek, mert azt írtad, az nem ajánlott.
Gondolom ez teljesen jó lenne, nem?
Az Enhanced Secure Erase miért nem ajánlott, az mit csinál még pluszban?"A Windows parancssorból kiadott lassú formázás 0-val írja felül az összes szektort, mint ahogy a DD is Linux alatt."
Mármint gondolom a Windows-os módszernél a /P kapcsolóval, ahogy janos666 itt írta. A Linuxos dd if=/dev/zero of=/dev/XXX (XXX persze az eszköz neve) gondolkodás nélkül, tényleg teleírja 0-kkal az összes elérhető szektort."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. AZ ATA Command Set specifikációban csak az van leírva, hogy az SE milyen bitmintával töltse ki a szektorokat(azt hiszem Enhanced-nél meg gyártó függő lehet), de hogy azt követően a Firmware meg a vezérlő milyen fizikai karbantartást végez vagy sem, az természetesen nincs meghatározva.
Az SE meg teljesen más elven "nullázza" a szektorokat, hisz pl utoljára a 120G-s 840-esemt 5 sec alatt törölte, míg ha lassú formázom, ott meg több percről beszélünk."
Ez alapján azt veszem le, hogy simán lehet értelme Samsung-eszközök esetén (is?) egy secure erase utáni lassú formázásnak IS. Végül is egy próbát simán megér, még ha sok írással is jár.+ még az előbbieken kívül (#13366) janos666 : a SRCD alatt gondolom a SystemRescueCd-t értitek, ez full Linuxos, amúgy ez is nagyon hasznos toolokat tartalmaz. Tuti ez is tud valahogy secure erase-t, konkrétan mondjuk nem tudom, hogyan, és szerintem ez megfelelő alternatívája lehet a Parted Magicnek a legtöbb esetben.
Köszi még egyszer, hogy ilyen alaposan kifejtettétek a szempontokat!
(#13392) Doky586 :
Még azt nem láttam tőled kifejtve, hogy miért jön egyáltalán a TRIM képbe, amikor egy secure erase-t és/vagy lassú formázást/0-kkal teleírást végzek az SSD-n? Itt például Live Linux bootolásáról beszélünk (vagy egy Windows-hoz kapcsolódó eszközről, tök mindegy), ami után majd olyan oprendszert rakok rá, amin nyilván lesz aktiválva a TRIM. De a fenti műveletek elvégzéséhez hogy jön?
És hogy jön ide, hogy használjon a kolléga XP-t? Nyilván nem azt használ, és nála is aktiválva van a TRIM."De mint már említettem ezt egy kicsit szerintem túlmisztifikáljátok. várom mikor pukkan ki a lufi. az egész nem éri meg a rá fordított időt."
Konkrétan mit érzel túlmisztifikálva? A secure erase-t? A 0-kkal való teleírást? Csak az SSD-nél érzed túlmisztifikálva, vagy úgy általában, HDD-nél is?Amúgy bocs, de feltételezem, hogy Fire/SOUL/CD kollégának jóval több tapasztalata és összehasonlítási alapja van ezek hatásosságában, mint neked vagy nekem (vagy a topicban tevékenykedők többségének), mert az azért kiderült már, hogy nem kevés számú eszközzel és kapcsolódó problémával találkozott már.
Igazából nem láttam tőled normálisan kifejtve egyszer sem, hogy most mi is hülyeség, csak némi odavetett lefitymáló megjegyzést, pedig érdekes lenne átrágni (engem legalábbis érdekelne a Te normális magyarázatod is).
[ Szerkesztve ]
Sk8erPeter
-
#13420
Sk8erPeter
nagyúr
Doky586
#13416
Sk8erPeter
nagyúr
válasz
Doky586
#13416
üzenetére
"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
-
válasz
Doky586
#13416
üzenetére
É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álniMost 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."
-
ubyegon2
nagyúr
Sziasztok!
Linuxot (MINT17 64bit) telepítettem Intel 120 GB- ra és daily TRIM- et állítottam be remélhetőleg sikerrel. Alapból már kezelte a Linux a TRIM- et . Optimális az SSD- nek a napi TRIM beállítása, ha ezzel a beállítással így működik?
Tudtod még más javasolt optimalizálást Linux alatt? Minden 5let jól jön, mert eddig csak HDD- t használtam, most üzemeltem be először SSD- t, de úgy néz ki, hogy nem volt rossz 5let, pedig a WD1003FZEX sebességével is meg voltam elégedve. Azért az Intel 520- al érződik egy kis ugrás a sebességben.
Erről jut eszembe, Linuxra nem tudtok Win- es tesztelő programhoz hasonlót?
előre is
[ Szerkesztve ]
Samsung 860 EVO 1TB SSD 30eft 6,7TB írás még garis
-
#13475
Fire/SOUL/CD
félisten
pinnacle
#13470
válasz
pinnacle
#13470
üzenetére
Még nem kaptam meg az email-t (megnéztem, SPAM-ben sincs).
Ettől függetlenül már bekerült a SMARt adatbázisba, meg pár darab Kingfast is(amit lehet modell alapján azonosítani), az SSDOK következő változata már megjelenít SMART adatokat is a fennemlített meghajtókról, de az E-mail-t azért jó lenne megkapni.ubyegon2
Az FSTRIM az nem valós trim, az csak kb az üres terület karbantartásával megegyező karbantartás. A valós TRIM az az fstab fájl módosításával jár, a discard paraméter alkalmazásával, de ezt csak akkor célszerű alkalmazni, ha nincs kitéve nagy mennyiségű írásnak/törlésnek kis fájlokon az SSD, mert a Linux ebben még nincs a toppon...
Ezt csak a tisztánlátás kedvéért írtam, a valóságban valóban célszerűbb az fstrim időszakonkénti vagy időzített futtatása.[ Szerkesztve ]
Mindenki tudja, hogy bizonyos dolgokat nem lehet megvalósítani, mígnem jön valaki, aki erről nem tud, és megvalósítja. (Albert Einstein)
-
#13505
ubyegon2
nagyúr
Fire/SOUL/CD
#13475
ubyegon2
nagyúr
válasz
Fire/SOUL/CD
#13475
üzenetére
Értem, köszönöm!
ha nincs kitéve nagy mennyiségű írásnak/törlésnek kis fájlokon az SSD
Csak a Linux disztró/k és a FF fut róla. Ezzel ki van téve nagy mennyiségű írásnak/törlésnek kis fájlokon?
A /home mappa is HDD- re van partícionálva, ott mozoghatnak az adatok nyugodtan.Az fstrim script benne van a /etc/cron.weekly mappában, ezek szerint lefut hetente. Fentiek ismeretében jobb lenne törölnöm a /etc/cron.daily mappából a trim scriptet?
Samsung 860 EVO 1TB SSD 30eft 6,7TB írás még garis
-
ubyegon2
nagyúr
válasz
arm1n_
#14268
üzenetére
sudo blockdev --getalignoff /dev/sda
ez a parancs terminalból leellenőrzi, hogy az alignálás rendben van- e.sudo hdparm -I /dev/sda | grep "TRIM supported"
ez ellenőrzi, hogy a TRIM támogatott-eA fenti példákban sda van meghajtóként feltüntetve, ha nálad nem sda a meghajtó, akkor azt módosítsd!
A többi teendő előtt szükséges az SSD és a Linux pontos meghatározása.
Gondolom a friss firmware van az SSD-n.[ Szerkesztve ]
Samsung 860 EVO 1TB SSD 30eft 6,7TB írás még garis
-
ubyegon2
nagyúr
válasz
arm1n_
#14271
üzenetére
2 jó hírrel kezdem. Az Ubi 14.04- től támogatja az Intel és a Samsung SSD-ket!
Ha nem állítgatsz semmit, akkor is jól fogja kezelni az SSD- t a Linuxod. A TRIM engedélyezve van, heti rendszerességgel fut.Eléggé foglakoztatott engem is ez az SSD Linuxon téma, nem nagyon van leírás, segítség, hogy mit hogyan. Össze kéne hozni egy cikket erről is, már Win 7- 8 alá egész sok jó cikk van!
Sebességet a Lemezek gnome-disk-utility nevű program tud mérni, de csak ha nem fut SSD- n az oprendszer, így liveból tutod megtenni ezt.sudo dmesg | grep -i sata | grep 'link up'
SATA link ellenőrzése, ebből megtudod, hogy SATA1, 2 vagy 3 átvitelt alkalmaz a Linux.sudo hdparm -Tt /dev/sda
lemezolvasás ellenőrzésesudo dmesg | grep -i --color ahci
AHCI ellenőrzésesudo smartctl --all /dev/sda
SMART ellenőrzéscat /sys/block/sda/queue/scheduler
noop [deadline] cfq
I/O ütemező ellenőrzése, a bejelöltet használja a meghajtóEzeket nézegesd meg, addig keresgélek még.
Mozgatsz nagy állományokat az SSD- n? Alapvetően milyen felhasználói profilja van a gépnek? Van- e más meghajtó a gépben? milyen böngészőt használsz?[ Szerkesztve ]
Samsung 860 EVO 1TB SSD 30eft 6,7TB írás még garis
-
válasz
ubyegon2
#14272
üzenetére
"Az Ubi 14.04- től támogatja az Intel és a Samsung SSD-ket!"
Eszerint az összes többit (Adata, Kingston, stb) NEM támogatja???"A TRIM engedélyezve van, heti rendszerességgel fut"
Ezt a Win7-8 valós időben állandóan kezeli. A linuxra csak ilyen offline verzió van mint XP-re..? -
#14274
Fire/SOUL/CD
félisten
Doky586
#14273
válasz
Doky586
#14273
üzenetére
"Eszerint az összes többit (Adata, Kingston, stb) NEM támogatja???"
Ezt én sem igazán értem, hogy itt mire is gondolt ubyegon2 topiktárs, de érdeklődéssel várom a válaszát."Ezt a Win7-8 valós időben állandóan kezeli. A linuxra csak ilyen offline verzió van mint XP-re..?"
Nem, csak alapból nincs bekapcsolva. Ahhoz az fstab szerkesztése szükséges a képen látható discard paraméter beszúrásával (és restart).
Ezért nem alapértelmezett. | TRIM vs. fstrim[ Szerkesztve ]
Mindenki tudja, hogy bizonyos dolgokat nem lehet megvalósítani, mígnem jön valaki, aki erről nem tud, és megvalósítja. (Albert Einstein)
-
ubyegon2
nagyúr
válasz
Doky586
#14273
üzenetére
Linuxon 14.04- től alapból engedélyezve van a heti rendszeresség, de cron-ban beállíthatod, milyen sűrűn akarod lefuttatni, szerintem ha nem nagyon sok írás van, akkor bőven elég a heti egy, ezt úgy tudom boot/alatt előtt csinálja, emiatt a 24/7- ben futó gépeknél meg kell adni egyparamétert hozzá, hogy lefusson a beállított időközökben. Akár terminalból is TRIM- melhetsz, ha nem állítasz be semmit. Ez egyébként jobb, mint Win7-8 valós idjű kezelése, mivel úgy állítod be, ahogy akarod. Csak nem kell ezt a csoda TRIM- et állandóan figyelgetni!
Lassan kezdem kapisgálni a win/linux logikájának a különbségét, így már azt is sejtem, miért gyorsabb és kisebb erőforrású a Linux, mint a Win.A többi SSD- vel nem működött még optimálisan a TRIM, így azt kézzel kell beállítani igény szerint beállítva fentiek szerint. 14.10 verzióról még nincs elég infó, lehet, hogy már abban támogatott lesz a többi SSD is.
(#14274) Fire/SOUL/CD
Ahhoz az fstab szerkesztése szükséges a képen látható discard paraméter beszúrásával (és restart).Több helyen írták, hogy a discard opció mellőzendő, viszont a noatime erősen javallott helyette!
Ezekről mi a véleményetek?
Szerinted van esély, hogy hozzáértők annyi okosságot összeszedjenek a Linux/SSD párosról, hogy egy cikk összejöjjön belőle vagy legalább kiegészítés a Win- es írásokhoz?
Samsung 860 EVO 1TB SSD 30eft 6,7TB írás még garis
-
ubyegon2
nagyúr
válasz
janos666
#14300
üzenetére
"Igen, minden SSD-n ülő partícióhoz fűzd oda a discard paramétert, és ha ez megvan, akkor tiltsd le az fstrim ütemezést.
A noatime-ot pedig SSD-n és HDD-n lévő partíciók filerendszereihez is használhatod"Ezek szerint elég lenne csak SSD- re berakni fstab- ba a discard, noatime- ot. Nálam viszont nincs felcsatolva minden partíció Linux alatt, két Win7- es partíciót nem tartottam szükségesnek például! Okozhat ez gondot, mert így csak az SSD egy részére vonatkozik a végrehajtási parancs?!
Érdemes felcsatolnom az összes partíciót, hogy optimálisan működjön a TRIM?
(#14302) berus.berus
Csak törlöm innen és kész? Köszi!
[ Szerkesztve ]
Samsung 860 EVO 1TB SSD 30eft 6,7TB írás még garis
-
#21078528
törölt tag
válasz
arm1n_
#14309
üzenetére
Mivel többször felmerült itt a fórumon, egy gyors Linux+ SSD összefoglaló, ahogy én szoktam, tehát nem biztos, hogy így a legjobb, mindenki csak saját felelősségre, és tessék tájékozódni több forrásból!
Partícionálás:
Érdemes a GParted programmal csinálni (több LiveCD-s terjesztésen megtalálható, GParted Live, SysRescueCD, stb.) így biztosan jó lesz az alignálás, alapból helyesen ajánlja fel. Lényeg, hogy az első partíciónak a 2048-as szektornál kell kezdődnie!
Alignálás ellenőrzése:
fdisk -l /dev/sda | grep -E sda[0-9]+ | sed s/*// |
awk '{printf ("%s %f ",$1,$2/512); if($2%512) { print "ROSSZ" }else {print "OK"} }' | column -t
Ne feledjük, minél több helyet hagyunk szabadon a meghajtón, a vezérlő annál jobban érzi magát!
Ha rendelkezünk HDD-vel is, megfontolandó a /var könyvtár (gyakran módosuló adatok) és a swap HDD-re rakása.
Ezenkívül érdemes a /tmp könyvtárat tmpfssel a RAM-ba rakni (ezt néhány terjesztés alapból megteszi).
Ehhez az /etc/fstab fájlba írjuk a következő sort:
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0Fájlrendszer, TRIM, ütemező:
A TRIM-nek két megvalósítása van Linuxxon, az /etc/fstab fájlba írt discard opció, ill. az fstrim parancs.
A discard hatására az OS közli a vezérlővel, hogy az adott adat logikailag már nem létezik, valósan törölhető. Régebbi meghajtóknál ez azonnal végrehajtódik, ezért sok kis fájl esetén teljesítmény problémákat okozhat. Az újabb queued TRIM (SATA rev. 3.1) eljárást ismerőknél viszont a blokkok felszabadítása nem (feltétlen) történik meg azonnal, a teljesítmény csökkenés veszélye kevésbé áll fenn.
Discard az /etc/fstab fájlban (példa):
UUID=f0ae2c59-83d2-42e7-81c4-2e870b6b255d / ext4 discard,errors=remount-ro 0 1Az fstrim parancs megvizsgálja a meghajtót, és alapértelmezésben az összes felszabadítható blokkot "törli".
Tipikus formája:
fstrim -v /csatolási pont
Kiadható manuálisan, de célravezetőbb boot szkriptbe (pl. rc.local) tenni, vagy cron feladatot létrehozni belőle, napi futtatással.
Hogy melyiket érdemes használni, azt nagyban befolyásolják a felhasználói szokások, én a magam részéről a discard opciót favorizálom.
Jelenleg a következő Linuxxos fájlrendszerek támogatják a TRIM funkciót: EXT4, Btrfs, JFS, XFS, Reiser4 (még nincs a hivatalos kernelfában).Érdemes lehet az I/O ütemezőt cfq-ról deadline-ra, ill. csak SSD használat esetén noop-ra állítani.
Jelenlegi ütemező lekérdezése:
cat /sys/block/sda/queue/scheduler
Az ütemezőt legegyszerűbb az /etc/default/grub fájl megfelelő sorának módosításával állítani (példánkban deadline-ra):
GRUB_CMDLINE_LINUX_DEFAULT="elevator=deadline quiet splash"
Majd futtassuk az update-grub parancsot! A beállítás a következő rendszer töltéskor lép érvénybe.Egyéb ötletek:
A meghajtó kímélése és a teljesítmény növelése miatt fontos lehet a noatime csatolási opció beállítása az /etc/fstab fájlban, így nem kerül kiírásra az utolsó fájlhozzáférés időbélyege.Ha a swap SSD-re kerül, próbáljuk csökkenteni a swap használatot a swappiness érték (alapértelmezésben 60) csökkentésével.
Ehhez írjuk az alábbi sort az /etc/sysctl.conf fájlba:
vm.swappiness=10A meghajtón rendben van-e a TRIM:
hdparm -I /dev/sda | grep TRIM
Válaszként ezt kell látnunk: "Data Set Management TRIM supported (limit 1 block)".Terjesztésenként változhatnak a fentebb említett fájlok elérési útjai!
Irodalomként az Arch Linux idevágó wiki oldalát ajánlom!Hirtelen ennyi jutott eszembe...
[ Szerkesztve ]
-
#14480
janos666
nagyúr
Sk8erPeter
#14479
válasz
Sk8erPeter
#14479
üzenetére
Igen, ezért.
Bár én sem vagyok benne biztos, hogy a legtöbb particionáló program TRIM-eli vagy sem az összes LBA szektort, mikor törlöd a partícióinformációkat (pl. diskpart féle CLEAN paranccsal), mert még nem próbáltam ki, de vakon inkább azt feltételezem, hogy nem.
Szóval, ha ezt az utat választanám, akkor vagy secure erase-el kezdenék, vagy feldobnék oda átmenetileg egy új partíciót, majd Linux alatt TRIM-elném blkdiscar-al (ezzel lehet partíciót is TRIM-elni), vagy Windows alatt létrehoznék egy NTFS filrendszert, amit defrag x: /L paranccsal TRIM-elnék végig, majd ezt követően törölném ezt az átmeneti partíciót. Így nyugodt lennék, hogy szólt valaki az SSD-nek arról, hogy azok az LBA szektorok, amik a partícionálatlan területre esnek, üresek ()nem pedig valami random statikus kacatot cipel magával, mert az inkább árt, mint segít).
---
Közben felhúztam az asztali gépre a Win10 TP build-ot úgy, ahogy múltkor kipróbáltam egy tartalék HDD-vel:
32Mb-os EFI partíció 1Mb offset után, FAT16 8192byte-os AU-val formázva
maradék terület egyben NTFS, szintén 8192byte-os AU-val
(és ezen felül semmi más hulladék partíció vagy partícionálatlan terület)Egyelőre van egy kis placebóm, hogy mint ha picit pörgősebb lenne az OS, de nyilván az is benne van ilyenkor a dolgokban, hogy frissen van telepítve, nincs még teleszemetelve, több még a hely az SSD-n, na meg maga az OS is új. (A beépített kémprogramjait kigyilkoltam a telepítés során.)
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."
-
#14534
#21078528
törölt tag
Sk8erPeter
#14527
#21078528
törölt tag
válasz
Sk8erPeter
#14527
üzenetére
Most janos666 kolléga megjegyzése alapján particionálatlan terület nélkül formáztam meg a meghajtó, és méregetek, hogyan alakulnak a sebességek.
Minden esetre igyekeztem tájékozódni, és előfordulhat, hogy pakolászik a vezérlő szükségtelen adatokat a particionálatlan területen, de elvileg a vezérlőnek (garbage collection rutin pl.) előbb-utóbb rá kell jönnie, hogy az adat törölhető.
Márt csak azért is gondolom, hogy működnie kell a dolognak, mert mint korábban említettem, van ismerős, aki ReiserFS-sel használja a gépet, ami nem ismeri a TRIM-met, és még sincs gond a meghajtó sebességével és állapotával, viszont sok szabad helyet hagyott (particionálatlan terület). Illetve a titkosított partíciók (cryptoloop) is divatosak manapság Linuxon, és ugye ekkor sincs TRIM, és panasz se, hogy lassulna a meghajtó.
Minden esetre tényleg érdekes kérdés, meglátom, hogy ezzel a particionálási sémával változik-e valami nálam...
Annyit még kiokoskodtam, hogy a TRIM-met ismerő Linuxos fájlrendszerek a fájlrendszer létrehozásakor kiküldik a TRIM parancsot, de az már nem derül ki, hogy a teljes meghajtóra, vagy csak a particionált területre, de szinte biztos, hogy az utóbbi...
Még régebbről van valami emlékem (wikin is van rá utalás), hogy a Samsungnak volt valami BGC eljárása, ami figyelt a fájlrendszerre is és a particionálatlan területre is, pont a tárgyalt probléma miatt, de nem tudom, hogy ténylegesen alkalmazzák-e, vagy mi lett a sorsa. -
#14789
Sk8erPeter
nagyúr
janos666
#14769
Sk8erPeter
nagyúr
válasz
janos666
#14769
üzenetére
(#14769), (#14552), (#14603), (#14766)
Bocs, hogy csak most válaszolok, kicsit sok volt a dolog mostanság, aztán meg halasztgattam a dolgot, mert a normális válaszadáshoz gondolkodóképességre is szükség van.Jó, hogy tesztelted, akkor megtudtuk, hogy a Windows diskpart eszközével sem a partíciótörlés, sem a partíció-létrehozás NEM jár TRIM-meléssel. Nagyon valószínűnek tartom, hogy ugyanígy a Linuxos partíciókezelő eszközök használata esetén sem.
Egyébként azért jobban belegondolva ebben azért van (lehet) logika: pl. elképzelhető olyan eset, hogy véletlenül törölsz partíciókat, de aztán vissza akarod állítani (van mód partícióstruktúra helyreállítására). Ekkor nem igazán járnánk jól, ha már szépen ki lenne nullázva a francba az ott található terület.
Ez alapján meg visszakapcsolódunk ahhoz, amit levezettél: ha a particionálatlan területen ott terpeszkednek az "ottmaradt" 1-esek és 0-k, és senki nem szólt az SSD-nek, hogy az a terület bizony felszabadítható, akkor az itt lévő adatot statikus, meghagyandó adatnak érzékelheti, így a wear leveling során ezt is toszigálja ide-oda. (Most csak levezettem magamnak saját szavakkal is, amit kb. írtál.
)
Ez alapján tényleg kifejezetten ROSSZ lehet a particionálatlan terület meghagyása, ha nincs előtte secure erase-elve az SSD (hanem pl. egy korábbi partícióstruktúrát simán partíciókezelővel töröltünk, és létrehozogattunk újakat (vagy csak egyet), és hagytunk egy félrerakott, particionálatlan területet is, mert az eddigi elképzelések szerint az jót tesz az SSD-nek, pedig a gondolatmenet alapján nem (nem biztos)).
Ez mondjuk kiábrándító, ha valóban így van.Tényleg kíváncsi lennék, hogy van-e erre bármi áthidaló módszer, mert ha ez a levezetés igaz, akkor szerintem nagyon sokan rosszul használják az SSD-jüket, és úgy, hogy az kifejezetten káros is az élettartamra (hiszen akkor lehet, hogy a wear leveling során sokkal nagyobb adatmennyiséget kell mozgatni, mint amire számítunk, és sokkal inkább telítve lehet az SSD alacsonyabb szinten, mint arra számítunk - hiszen senki nem TRIM-elte azokat az ominózus particionálatlan területeket, ha nem volt előtte secure erase).
Meg az is valóban érdekes kérdés lehet, hogy amikor mondjuk a Samsung Magiciannel választasz le az over provisioning miatt egy adott területet, akkor vajon a progi megfelelően kommunikál-e az SSD-vel a TRIM-elési feladatokról.Sk8erPeter
-
#14797
#21078528
törölt tag
Sk8erPeter
#14789
#21078528
törölt tag
válasz
Sk8erPeter
#14789
üzenetére
A Linuxos mkfs parancs küld TRIM parancsot a fájlrendszer létrehozásakor (EXT4 és Btrfs esetén biztosan, JFS-nek, XFS-nek utána kéne nézni).
[ Szerkesztve ]
-
Ha tesztelni szeretnél, engem jobban érdekelne, hogy:
- most futtatsz egy olvasási tesztet
- Live Linux-ból blkdiscard-al TRIM-eled a particionálatlan területet (legegyszerűbb, ha felraksz egy átmeneti particiót, TRIM-eled a RAW particiót, aztán törlöd -> sőt, ezt igazából Windows-ból is megteheted: create partition, format quick, assign, defrag e: /L , delete partition).
- megismétled az olvasási tesztetBár megint SandForce... nem biztos, hogy úgy reagál a TRIM-re, mint a legtöbb SSD vezérlő, szóval szerintem nem változna semmi.
Következőben pedig hagynám a refresher-t, helyette
- készítenék egy backup-ot (de a file-okról, nem a nyers szektorokról + MBR-t, vagyis az első blokk DD-vel)
- secure erase
- restore (MBR DD-s visszaállítása után a file-ok visszamásolása, pl egy-egy TAR file-ból kibontva)
- új olvasás tesztAmúgy...
"beáldozok mindjárt még kb. 55GB-nyi írást"
Vigyázz, mielőtt terroristának bélyegeznek az ilyesmikért.[ 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."
-
p.lac
tag
válasz
janos666
#14849
üzenetére
Linuxot használok amúgy, csak van fent dísznek egy W7 is.
[root@localhost /home/lac]# while IFS=: read -ra FREE
> do
> echo blkdiscard --offset ${FREE[1]%%B} --length ${FREE[3]%%B} /dev/sda
> done < <(parted -m /dev/sda unit b print free | grep ':free;')
blkdiscard --offset 32256 --length 1016320 /dev/sda
blkdiscard --offset 48485105664 --length 11537375232 /dev/sdaMit szólnál, ha lefuttatnám a fent kiemelt blkdiscardot? Elvileg ez kell nekünk, trimmeli a 10GB-os partícionálatlan területet.
-
#21078528
törölt tag
válasz
ubyegon2
#14857
üzenetére
Ha a teljes területet particionálod, akkor biztosan nem kell secure erase! Mint korábban írtam, EXT4, Btrfs a fájlrendszer létrehozásakor küld TRIM parancsot.
Linux secure erase témában ezt nézd át:
Arch wiki.SATA ellenőrzése:
smartctl -a /dev/sda | grep SATAHa az Arch Linuxxal csak kísérletezni akarsz kár szétszedni az SSD-t, telepíts egy VirtualBoxxot v. Qemut és rakd fel az alá...
-
#14915
Sk8erPeter
nagyúr
Doky586
#14914
Sk8erPeter
nagyúr
válasz
Doky586
#14914
üzenetére
Ezt írta ő is: "ugyanakkor a 4k alatti AU méretnek már érdembeli negatív hatása van".
(#14878) Doky586:
Na, tehát összességében elmondható, hogy ezek szerint Te is azt az álláspontot erősíted, hogy amennyiben nem secure erase után raktunk félre particionálatlan területet, hanem előtte azon a területen mondjuk adatok voltak, akkor mivel sima Windows-os eszközökkel történő újraparticionálás során ezek nem TRIM-elődnek, a wear leveling során kvázi statikus adatokként tilitolizódnak ide-oda, ergo olyan, mintha az SSD jobban tele lenne, mint hinnénk.DE továbbra is kérdés számomra, mi van az újabb (>7) Windows-ok háttértár-kezelős GUI-ja mögött, nincs-e TRIM, ahogy az újabb Linuxok partíciókezelőinél a partíciótörlés során...
[ Szerkesztve ]
Sk8erPeter
-
#14918
p.lac
tag
Sk8erPeter
#14915
p.lac
tag
válasz
Sk8erPeter
#14915
üzenetére
"DE továbbra is kérdés számomra, mi van az újabb (>7) Windows-ok háttértár-kezelős GUI-ja mögött, nincs-e TRIM, ahogy az újabb Linuxok partíciókezelőinél a partíciótörlés során..."
Amit a hivatkozott hozzászólásban berus.berus írt: "A Linuxos mkfs parancs küld TRIM parancsot a fájlrendszer létrehozásakor" az számomra azt jelenti, hogy a partíción a fájlrendszer létrehozásakor az mkfs küld TRIM parancsot, de ez nem egyenlő a partíció törléssel.
[ Szerkesztve ]
-
Adott egy 2007-es noti, feltuningolva egy V300-as SSD-vel. Gyárilag Vista van rajt, így nem támogatja azTRIM-et.
- Létezik olyan freeware program amivel időnként trimmelhető?
- Ha dualboot-os kivitelben indőnként linux is fut rajt, az kiadja magától a trimmelés parancsot? (Ami az egész lemezre érvényes, vagy csak a linux os partíciókra?)Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews
-
#17953
Siriusb
veterán
Fire/SOUL/CD
#17952
Siriusb
veterán
válasz
Fire/SOUL/CD
#17952
üzenetére
Kösz a válaszod.
Linuxról van szó, és cryptsetup fejlesztő írt a biztonsági problémáról, amit a TRIM felvet: Milan Broz's blog
-
válasz
cyberkind
#18609
üzenetére
Apropó windows: első közelítésben ne tégy fel semmilyen chipset vagy SATA-drivert, bezavarhat a TRIM-működésébe (az alap win8-as driverekkel mennie kell).
Tényleg, kérdés a szakikhoz: linux (ubuntu/xubuntu) alatt mire figyeljen az ember?
[ Szerkesztve ]
30€ Meta store bónusz Quest headset aktiváláshoz, keress priviben :)
-
#93794560
törölt tag
Sziasztok!
Nem tudom, hogy jó helyre írok-e, mert SSD-ről és Linuxról is szó van a dologban. Egy ismerős hozzám fordult egy olyan ügyben, hogy új SSD-t venne, és erre Linux-ot szeretne telepíteni. Ha jól emlékszem, talán a legújabb Linpus 2.2-t, mert ezt ő nagyon szereti. Mivel én ilyet csak egyszer láttam, és az is HDD-ről ment, nem tudtam neki válaszolni arra, hogy ez a rendszer kezeli-e rendesen a TRIM-et, és az egyéb SSD-n fontos funkciókat, anélkül, hogy mindenféle rendszerbuherálásokat kellene elvégezni. Utánanéztem a Linpus oldalán, ez a legújabb már támogatja a Haswell procikat, és a Secure Boot funkciót UEFI-ben.
Örülnék neki, ha valaki tudná rá a választ, mert nem akarok itt ülni tudatlanul, főleg, ha tőlem várják azt, hogy segítsek.
Vagy forduljak inkább a Linux-os topic-ba?Előre is köszi!
-
HSM
félisten
válasz
ubyegon2
#19750
üzenetére
Hát nem tudom, én nem vagyok Linux-guru.
Viszont nagyon érdekes, hogy a Kernel ilyen jellegű hibákat is okozhat, meghajtófüggően.
Kíváncsi leszek a továbbiakra, ennek előbb utóbb úgyis lesz Linux-os visszhangja is. Azt azért nem merem feltételezni sem, hogy a Linux kernelre fogják, ha esetleg mégsem az lenne a sáros. Az azért nagyon gázos lenne, és igen hamar kiderülne....Nekem amúgy az már az elejétől fura volt, hogy Windows-on hibátlan a TRIM (saját 840 PRO-mon se tűnt el egy ára file se soha, pedig már 6TB írásnál tartok), szóval volt egy sejtésem, hogy ez egy fura hiba lesz, nem feltétlen a meghajtóval....
-
HSM
félisten
válasz
waveson
#20445
üzenetére
"gyakorlatilag 7,5TB írás után elhullott. a RAID5 ellenére olyan gagyi volt ez a 840pro-s samu, hogy az adatbázist részlegesen hazavágta.
"Linux alatt volt valami hiba, ami TRIM esetén adatkorrupcióhoz vezetett ezekkel. Ha RAID5-ben hazavágta a database-t, akkor ez lehetett a hunyó.
(#20451) waveson: Ha ilyen mennyiségeket írsz rá (ha jól látom, 2 hét alatt 16TB) ilyen sebességgel, akkor lehet, hogy csak időt kéne neki hagyni, hogy a TRIM összekalapálja a meghajtót, amíg békében hagyod. Vagy egy teljes "reset", vagy "performance optimization", de itt nem 0-val teleírásra, vagy formázásra gondolok, hanem teljes cellaszintű helyreállításra.
Egyébként egy 840 PRO-t 5 év garanciával adnak, és ha jól emlékszem, durván 75TB írásig állják érte a felelősséget, tehát 7,5TB-al még bőven garis vagy elvileg. -
#20682
King Unique
titán
Bodor
#20679
King Unique
titán
Ezt már fentebb írtam, hogy a program serint nem működik a TRIM.
Akkor vsz tényleg nem, ha ez azt írja.(#20680) ubyegon2: majd továbbítom felé, de ha Windows az adott program szerint nem, akkor gondolom Linux alatt sem.
Köszönöm az ötleteket. Bár nagyon úgy néz ki, magamnak kell ezt majd alaposabban letesztelnem, ha pontos választ akarok.
[ Szerkesztve ]
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?
)
)
"
Új hozzászólás Aktív témák
-
(rögzített hozzászólás)
Kedves Fórumozók!
Frissítettem az összefoglalót, valamint a topik neve is változott.
Remélem ezekkel a változásokkal itt több tapasztalat/eszme csere fog létrejönni, mivel kicsit szabadabb, lazább lehete ezentúl ez a topik.Mindenkinek további jó fórumozást!
Pyttawrx- Tudástár Az SSD kondíciója, tények és tévhitek
- Tudástár Windows 7/8/10 SSD-vel! Hogyan is?
- Elemzés Átfogó elemzés az SSD-k természetéről
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen