- Samsung Galaxy A54 - türelemjáték
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Android alkalmazások - szoftver kibeszélő topik
- iPhone topik
- Ár-érték bajnokot avatott a Poco?
- Így lesz tégla a porszívódból - a Roidmi csődje
- Apple iPhone 16 Pro - rutinvizsga
- Nem nyílnak a Foldok?
- Ultrafényes Pixel karórák érkeznek
- iOS alkalmazások
-
Mobilarena
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
-
-
Doky586
félisten
几经研商，最后马英九同意，把年终慰问金的发放门槛，从月退俸2万元以下，提高到2万5千元，发放员额从原本的7万人增加至12万人（若不设门槛全面恢复则有44万人，国库负担高达190亿），马英九并公开表示：“若经济情况好转，未来可以再检讨调整”，虽然与原来全面恢复仍存在很大差异，但总算是对退休军公教人员的怒气，做了一番交代。
只不过，此举不但被绿营指责是“政策买票”，也引起身为连胜文市政顾问团成员之一的前卫生署长杨志良不满。杨志良公开呼吁连胜文，“反正胜选无望，留点骨气，叫这些死要钱的叔叔、伯伯滚回去吧！”引发一些浅蓝选票对“失去改革初衷”的不满；一正一负之间，究竟能增加多少选票？不无疑问。 -
janos666
nagyúr
"Vagyis nem olvas-módosít-töröl-ír, hanem olvas(A blokkot)-ír(B blokkba az A blokkból az érvényes page-eket)-töröl(A blokkot)."
Ha tovább bonyolítjuk a kérdést a GC-vel, akkor igen.
De megint idézem és pingálom az eredeti mondatom:"Tehát ilyenkor kénytelenek vagyunk akár olyat is csinálni, hogy olvas-módosít-töröl-ír."
Szerintem ez a mondat sem azt fejezi ki, hogy ez lenne a leggyakrabban, mértékadó helyzetben, vagy akár csak sűrűn előforduló eset, hanem egy bizonyos (még a 2010-es cikkből idézett szövegben felvetett) lehetséges felállás.
(Sőt, igazából még az is lehet, hogy a cikk szerzője egyszerűen hibázott | akár félreértett akkoriban valamit, vagy rosszul sikerült megfogalmaznia a gondolatait és a mondata mást jelent, mint amire gondolt | és most csak mi magyaráztuk meg, hogy igazából úgy is igaza van. Bárkivel bármikor megeshet. De ennyire messzire talán már tényleg ne menjünk.
) -
#14948
FollowTheORI
nagyúr
p.lac
#14946
Ájj... kicsit félreértettem a dolgokat amit írtok.
Szóval azt akartam mondani, hogy a lehető legritkább esetben van az az eset amiről beszéltek. Hogy valamit ki kell olvasni, módosítani, törölni ugyanazt a cellát és visszaírni. Előfordulhat, de ez csak nagyon teli meghajtón és nagyon ritkán. Még TRIM-el sem, mert azis ritkán történik meg úgy egy azonos cellán (hogy kiolvas módosít töröl újraír azonnal ugyanazt).
Szóval amikor az SSD ír, akkor valójában is csak ír a letöbb esetben egyszer, egy üres/törölt helyre.
Ettől függetlenül párhuzamosan, pl üresjáratban is folyik a felszabadult blokkok törlése a háttérben, ha van TRIM vagy valami belső jól működö GC. Ezért jobb a TRIM mint az ha nincs, mert gyakorlatilag az esetek jeletős többségében szinte mindig biztosítva van egy új üres lap/blokk íráskor (ha kell).
-
janos666
nagyúr
Bocs, először azt hittem, hogy a cikkből kimásolt szöveg van ellentmondásban önmagával, de félreértettem (pontosabban én először nem is vettem figyelembe azt a rész, mert nem tűnt közvetlen módon relevánsnak a saját kijelentéseimre nézve, csak akkor gondolkodtam el rajta, mikor kiemelted benne ezt a rész):
"Az SSD csak üres lap(ok)ra (4 kB-os egységek) írhatja fel az új adatokat, az érvénytelen adatokat tartalmazó lapok pedig ottmaradnak a helyükön, amíg szükség nem lesz a szabad területre. Ráadásul létezik még egy korlátozás, ami további problémát jelent: az SSD csak egy komplett blokk (512 kB, azaz 128 darab 4 kB-os lap) törlésére vagy felülírására képes."
Itt a FELÜLírás a kulcsszó.
Írni csak üres Page-re tudunk, üres Page-t pedig csak Erase Block törléssel tudunk csinálni. Ez nem jelenti azt, hogy minden Page felírásakor törölni kell egy Erase Block-ot, hogy legyen üres Page-ünk, mert általában lehet találni eleve üres Page-t is, ha TRIM-elünk és nem pakoljuk koppig az SSD-t (úgy, hogy még a host elől rejtett rész is dugig tömődjön). A felülírás viszont kifejezi, hogy a Page, amit módosítani szeretnénk, az nem üres. Ilyen esetben pedig csak úgy lesz üres az a felülírni kívánt Page, ha a teljes Erase Block-ot töröljük, amihez az a felülírni kívánt Page tartozik. Tehát ilyenkor kénytelenek vagyunk akár olyat is csinálni, hogy olvas-módosít-töröl-ír (jó lassan) egy egész Erase Block-on.De most segítséget kérek, hogy ez miként áll ellentmondással azzal, amit eredetileg írtam (figyelembe véve azt is, hogy TRIM-elünk, mert mostanság az a megszokott), mert bevallom, hogy ezzel most már talán elvesztettem a fonalat.
-
janos666
nagyúr
Nem kötekedésnek veszem, hanem lustaságnak, mert erre is úgy fogok válaszolni, hogy beszúrom a top5 google találatok közül azt a kettőt, ami első ránézésre a legrelevánsabbnak tűnik.
Ez a második google találat a micron.com-ról, vagyis "közvetlenül a ló szájából", ahogy az angolszász szerzője mondhatná (már ha valamiért lónak szeretné magát nevezni):
Ahol is ez olvasható:
“Page is the smallest unit of storage that can be written to, typically 4K or 8K."
De az első találat sem rossz:
http://codecapsule.com/2014/02/12/coding-for-ssds-part-2-architecture-of-an-ssd-and-benchmarking/
"Cells are grouped into a grid, called a block, and blocks are grouped into planes. The smallest unit through which a block can be read or written is a page. Pages cannot be erased individually, only whole blocks can be erased. The size of a NAND-flash page size can vary, and most drive have pages of size 2 KB, 4 KB, 8 KB or 16 KB. Most SSDs have blocks of 128 or 256 pages, which means that the size of a block can vary between 256 KB and 4 MB. For example, the Samsung SSD 840 EVO has blocks of size 2048 KB, and each block contains 256 pages of 8 KB each."
Az a pár Mb-os Erase Block, ami pár száz Page-ből áll, az szó szerint Erase Block, vagyis egy-egy ilyen blokk törölhető egyszerre. De az írás Page-enként történik.
De eleve csak gondolj be abba, hogy mennyire beb@szna, ha pl. a szintetikus random 4k írás teszt minden IOPS-ra 1-2Mb írást generálna az SSD-n belül. Futtatnád a sok tízezer IOPS-t generáló tesztedet, aztán hirtelen azon kapnád magad, hogy elhasználtál több tucat P/E ciklust (és valószínáleg tapinthatóan meleg az SSD pár perc után
![;]](//cdn.rios.hu/dl/s/v1.gif)
).
Egy nap alatt ki lehetne így nyírni egy 840 EVO-t (P/E ciklus elkoptatással vagy túlmelegedéssel), ha ez így működne, nem? -
#14921
Sk8erPeter
nagyúr
p.lac
#14918
Sk8erPeter
nagyúr
Igen, bocs, teljesen igazad van, azt sikerült végül elírni. Szóval nem a törlés során van TRIM (legalábbis az eredeti hsz. szerint), hanem a fájlrendszer létrehozásakor.
(#14919) janos666:
Érdekes lehet az is, hogy mi van a 7-es (6.1 SP1) GUI-ja mögött, és mi változott az efölötti Windows-okban (8.x és most már 10). Persze nem várom el, hogy mindet teszteld. Azért az elég sok tökölés lehet. Bár sok érdekesség megtudható lenne belőle (hogy kb. mi zajlik a háttérben, és mi változott ilyen tekintetben (ha egyáltalán) a különböző verziók közt)."Na meg legtöbben amúgy is telepítéskor particionálnak (kézileg vagy automatikusan), nem előre egy működő Windows alól. -> Igaz, az automata telepítős GUI-t sem teszteltem le, csakis a DISKPART-ot."
A legtöbben az automatikus particionálást választják, bevallom, többnyire engem sem érdekel a kérdés annyira, hogy ilyenkor kézzel hozzam létre a partíciókat (persze lehetne helyet spórolni, de őszintén szólva ilyenkor túl lusta vagyok ahhoz, hogy ezzel foglalkozzak, így talán szemedben szentségtöréssel egyenlő módon megelégszem a 100 MB-os System Reserved partícióval, és a maradék fennmaradó helyre a rendszerpartíciót automatikusan létrehozós módszerrel).
Szóval ja, az is érdekes lehet, hogy maga a telepítő GUI-ja ugyanazokat a műveleteket végzi-e el, ugyanazt az eszköztárat használja-e, mint maga a diskpart. 7-esnél még kb. azt feltételezném, hogy ja, de amúgy fingom sincs, a 8.x-vonalnál meg végképp nem tudom, mi változott ilyen tekintetben (annyi minden változott, hogy elképzelhetőnek/valószínűnek tartom, hogy ehhez is hozzányúltak).(#14916) Doky586:
"TRIM téma: igen, legalábbis arra szavaznék első körben. De meg lehet ezt tudományosabban is közelíteni: egy jól kidolgozott kisérlettel kimutatható melyik az igaz.."
Őőő, hát nyilván, de pontosan ez az, amire eddig senki nem tudta beáldozni az idejét... Ha neked van kedved, én nagyon kíváncsi lennék az eredményre. 
-
#14862
Atomnyuszi
csendes tag
p.lac
#14854
-
janos666
nagyúr
Úgy látom gyorsabban szülted meg a parancsot, mint hogy begépeltem az alternatívát.
Igen. Érdekelne. (Olvasás blkdiscard előtt és után).Aztán esetleg a másik, amit írtam, de ebben a sorrendben, és a második teszt csak úgy, ha a diskrefresh helyett csinálod, a kedvemért ne nyúzd.
Hmm... Ha nem egy HDD-n lévő VHD-ban lenne egy dísznek tartott Linux-om, akkor pont tele lenne a 128Gb-os SSD-m.
-
janos666
nagyúr
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. -
-
janos666
nagyúr
Ja, az a rész el is kerülte a figyelmem, hogy lassult a maximális olvasás, csak "nagy okosan" megmagyaráztam az érthető jelenséget.
Bocs.
Na, erre nem nagyon van ötletem.
Annyi vak tippem lenne, hogy mikor egy ilyen kvázi-folytonos és statikus elméleti felső korláttal is bíró folyamatban nő az átlag és csökken az ettől negatív irányba történő kilengés momentuma is, akkor ha nem is törvényszerű, de normálisnak tűnik, hogy csökken a pozitív irányba történő lengésé is (nincs olyasmi, hogy amikor "megbotlik" valamiben az egyik "keze", akkor közben a másikkal előre dolgozik egy bufferbe, amit aztán az elvi maximális sebességen tud továbbdobni, mielőtt ismét az átlaghoz kezd konvergálni ott, ahol nincs annyi kátyú az úton).
-> Ugyanakkor a particionálatlan LBA terület méréseire nagyon passzol ez az elmélet.Egy másik vak tipp, hogy eddig ugye sohasem használtad a particionálatlan terület LBA szektorait, most viszont igen (akkor is, ha csupa nullát olvasott ki és írt vissza a diskfresh program).
Szóval ... izé ... talán épp most bizonyítottad be ezzel a teszttel, hogy még a tömörítős SandForce vezérlőnek sem mindegy, hogy TRIM-elve van-e a partíció/filrendszer szinten üres LBA terület, még akkor sem, ha ott minden LBA csupa nullákkal van tele (de még sincs törölhetőnek jelölve TRIM-el).
-
janos666
nagyúr
Szerintem van rá magyarázat. Az újraírás segít "töredezettségmentesíteni".
A vezérlő több érthető okból is próbálja elkerüli azt, hogy saját szakállára írjon a NAND-ra, így alapvetően akkor ütyködik, mikor a SATA felől is kérnek tőle írást (kivéve, ha már muszály neki). Az új írásokat próbálja úgy végezni, hogy (fél/)passzívan elvégezze vele közben a "töredezettségmentesítést" is.
Ha így írsz rá (viszonylag nagy blokkokban, szekvenciális jelleggel), akkor közben kedvezőbben rendezi magát újra, mint ahogy korábban véletlenszerűen alakult (ha pl. OS van rajta).
Ez a "refresh" szekvenciális jellegű, a normál használat pedig részben random. A szekvenciális írás "töredezettségmentesíthet" (vagy legalább eleve nem tördel), a random "tördelhet" (mikor mennyire, de úgy általánosságban, előfordulhat, ha van időnként sok apró írás).Na meg SandForce-nál még tovább "tördelhet" a tömörítés is.
Úgy sejtem, hogy ehhez van köze annak, hogy a TRIM sem mindig éri el teljesen a várt hatást (ezeken a SandForce-okon), az ilyen "refresh" (mint a backup-restore is, főleg ha közben SE-t is kap) viszont igen.
)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
).
Új hozzászólás Aktív témák
Hirdetés
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
- Nyíregyháza és környéke adok-veszek-beszélgetek
- Könyvajánló
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Milyen egeret válasszak?
- Lakáshitel, lakásvásárlás
- Gitáros topic
- Gaming notebook topik
- Kínai és egyéb olcsó órák topikja
- Samsung Galaxy A54 - türelemjáték
- Milyen monitort vegyek?
- További aktív témák...
- Lexar NM790 2TB M.2 NVME PCI-E 4.0 x4 - Új - 7400-6500 MBs - Eladó!
- Szuper ár! 480GB Ipari Minőségű, Sata SSD-k, kevés írt adattal! PC-be és Laptopba is kiváló!
- Toshiba Enterprise Capacity MG09 18TB - 512MB, 7200rpm, SATA3 - 100/100 -as - Eladó!
- 1 Tb-os NVME-k különböző árak
- Kingston NV1 500GB M.2 2280 NVMe SSD
- iKing.Hu - Honor Magic V2 - Black - Használt, karmentes
- Telefon felvásárlás!! iPhone 12 Mini/iPhone 12/iPhone 12 Pro/iPhone 12 Pro Max
- ÚJ Asus TUF Gaming F17 FX707 - 17.3"FHD IPS 144Hz - i7-13620H - 16GB - 1TB - RTX 4060 - 3 év gari
- Konzol felvásárlás!! Xbox Series S, Xbox Series X
- BESZÁMÍTÁS! Lenovo Legion 5 15ITH6H Gamer notebook - i7 11800H 16GB DDR4 512GB SSD RTX 3060 6GB W11
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest