- Így állítsd be a gyermeked androidos készülékét
- Magisk
- Poco F5 - pokolian jó ajánlat
- Honor Magic5 Pro - kamerák bűvöletében
- Apple iPhone 13 - hízott, de jól áll neki!
- Samsung Galaxy A54 - türelemjáték
- Google Pixel 8 Pro - mestersége(s) az intelligencia
- Samsung Galaxy A55 - új év, régi stratégia
- Android szakmai topik
- Ezek a OnePlus 12 és 12R európai árai
Hirdetés
-
SMITE 2 - Napokon belül indul a zárt alfa teszt
gp Több mint egy tucat karaktert próbálhatnak ki a szerencsésebbek, a teljes listát a május első napján esedékes streamben árulják el.
-
Olcsó 5G-s ajánlatot nyújt a Realme Indiának
ma Megérkezett a Realme C65 5G, az első készülék a MediaTek Dimensity 6300-zal.
-
Lenovo Essential Wireless Combo
lo Lehet-e egy billentyűzet karcsú, elegáns és különleges? A Lenovo bebizonyította, hogy igen, de bosszantó is :)
-
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
-
Jester01
veterán
válasz Fire/SOUL/CD #74 üzenetére
Nem lényegtelen a töredezettség, mert a szekvenciális olvasás gyorsabb mint a random. Mint ahogy ezt a múltkor tesztadatokkal bizonyítottam is. Éppen csak az elhasználódás miatt nem éri meg defragmentálni (és mert a merevlemezhez képest még a random olvasás is elég gyors).
A lefoglalt terület elhelyezkedése pedig nem az SSD-től függ hanem a fájlrendszertől és természetesen nem mindig ilyen szépen az elején van.
Jester
-
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 worxland #1474 üzenetére
A pre-fail az nem azt jelenti. Csak azt, hogy ha rossz lesz az érték akkor meghibásodás várható.
Please note: the fact that an Attribute is of type 'Pre-fail' does not mean that your disk is about to fail! It only has this meaning if the Attribute's current Normalized value is less than or equal to the threshold value.
CRC error meg 18 van, semmiség.
Az írás viszont LBA-ban van úgyhogy az nem 2TB.
MOD: ok, tényleg lehet 2TB ha egy blokk itt 512 byte.[ Szerkesztve ]
Jester
-
Jester01
veterán
válasz Ice&Lime #1510 üzenetére
Általában a másolás úgy megy, hogy az elején csak olvas a memóriába (eddig gyors) majd idővel elkezd írni is és akkor persze csökken a sebesség. A 64-es samu 830 tiszta írási tempója amúgy is lassúcska, olyan 150MB/s körül van. Ha hozzáveszed, hogy olvasni is kell illetve a metaadatok miatt valószínűleg nem tisztán szekvenciális, a 90MB/s szerintem teljesen rendben van. (Már ha jól értelmezem a grafikonod.)
Merevlemez nagyjából századekkora sebességgel tudja ugyanezt
Jester
-
Jester01
veterán
válasz Balázs1986 #1555 üzenetére
Igenis javítana a sebességen mint ahogy azt kísérletileg is igazoltam. Józan paraszti ésszel is belátható, hogy a nem töredezett fájlt a szekvenciális sebességgel olvassa, a szélsőségesen töredezettet pedig a 4k sebességgel (ha 4k a blokkméret). A kettő között pedig jelentős különbség szokott lenni.
A wear levelling fizikai szinten dolgozik, annak ehhez pont semmi köze. A nem szekvenciális olvasás azért lassú, mert jóval több parancsot kell átküldeni az ssdnek illetve maga az ssd sem tud optimalizálni azzal, hogy belsőleg előre olvas.
A hétköznapi életben azért nem ajánlott a töredezettségmentesítés mert a mértéke általában kicsi és így nem befolyásolja annyira a sebességet hogy érdemes legyen feláldozni az ssd élettartamát. Különösen ha figyelembe vesszük, hogy még egy töredezett ssd is alaposan lekörözi a merevlemezeket.
Jester
-
Jester01
veterán
válasz Balázs1986 #1581 üzenetére
Igen, csak nagy fájloknál persze. Amiket egyébként lehetne (blokk-)szekvenciálisan olvasni.
Hangsúlyozom, valós használat közben általában nincs jelentősége.
A tesztem is annyi volt, hogy mesterségesen kreáltam egy 100% töredezett fájlt és egyszerűen lemértem az olvasási időt.
Jester
-
Jester01
veterán
-
Jester01
veterán
válasz Intel fan11 #1713 üzenetére
Elég lassú az autód, mert az enyém kétszer olyan gyors. Igaz, az enyém Ferrari
A 840-es írási sebessége gyári adat szerint 130MB/s, ezt még túl is teljesíti. Rendben van az.
lsc:
[ 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
-
Jester01
veterán
válasz Sturlung #1824 üzenetére
Nagyobb fájlt tudsz létrehozni mint amennyi hely van?
Mert ha nem akkor az nem sparse file hiszen a sparse file lényege hogy nem foglalja le a blokkokat az üres helynek. Ha pedig nem sparse a file, akkor viszont működhet amit csináltál. Erre tippelek.Elvileg nem rövidíti az élettartamot mivel a sparse file nem jelent írást (a metaadatokon kívül ami elhanyagolható) és a trim sem.
Jester
-
Jester01
veterán
-
Jester01
veterán
Maradjunk annyiban, hogy nem tudhatjuk milyen lesz annak a számnak az alakulása mivel azt az SSD maga adja meg ismeretlen adatokból ismeretlen módon számolva. Ha az alapérték exponenciális is, attól még a számítás módjában ezt lehet linearizálni.
[ Szerkesztve ]
Jester
-
Jester01
veterán
válasz F e Z o #2081 üzenetére
Az a legrosszabb eset ez meg a legjobb. A gyári adatokkal ezt lehet összemérni, tehát ez a jó arra, hogy az esetleges problémákat kiszűrjük. A "valós eredmény" (bármit is jelentsen) az a kettő között lesz, attól függően, hogy mennyire tömöríthető adatokkal dolgozik. De ezt biztos te is tudod, úgyhogy nem igazán értem miért hoztad fel.
Jester
-
Jester01
veterán
Ugyanúgy mint pl. memória inkompatibilitásnál, ha nem egyben vetted a konfigot akkor kompatibilitásra nincs garancia. Elvileg ugye szabványosak az interfészek, tehát vagy a vezérlő vagy a meghajtó igenis hibás. De hogy melyik, azt te az életben nem fogod tudni bizonyítani.
MOD: Persze ezen felül még szoftveres (driver) hiba is lehet.
[ Szerkesztve ]
Jester
-
Jester01
veterán
-
Jester01
veterán
egyenletesen terhelve a meghajtót?
Igen.
Az operációs rendszer által nem használt unallocated space-t ha hagyok a meghajtón, wear-leveling szempontból az is ki lesz használva?
Igen. A V300 amúgy is tömörítős sandforce, tehát fizikai üres hely még valószínűleg akkor is lesz ha teleírod (valamelyest tömöríthető adattal).
SMART figyelésre ott van még a hdsentinel is.
Jester
-
Jester01
veterán
válasz radi8tor #2195 üzenetére
4GB a megcímezhető memória korlátja 32 bites
operációs rendszernekdesktop windowsnak.Microsoft ezt a korlátozást mesterségesen vezette be, a piac szegmentálására, mivel egyébként semmi akadálya, hogy 32 bites rendszer több memóriát kezeljen mióta van PAE. Lásd akár a windows server kiadásokat.
[ Szerkesztve ]
Jester
-
Jester01
veterán
válasz Ice&Lime #6197 üzenetére
A basic az a kiszerelés nem pedig a modell neve. Ha a régi, sima 840-hez képest kérdezed akkor itt a cikk róla, de röviden:
"Az újabb S4LN045X01-8030 típusú chip immáron 400 MHz-es órajelen ketyeg, ami 33,3%-kal magasabb frekvenciát jelent az elődhöz képest. További újítás a SATA 3.1 szabvány támogatása [...] a 840 EVO-ban egészen pontosan 19 nm-es Toggle DDR 2.0 NAND lapkák kaptak helyet."
Jester
-
Jester01
veterán
válasz radi8tor #6750 üzenetére
Viszont ott is írják, hogy "Executing a SECURE ERASE function, such as that found in the Intel® SSD Toolbox, will cause the Intel SSD 320 Series drives to generate a new internal encryption key." Tehát attól, hogy le van jelszavazva még teljesen nyugodtan meg lehet venni mert törölni lehet és akkor újra használható. A jelszó csak az ellen véd, hogy az adatokat ne tudd kiolvasni.
Jester
Új hozzászólás Aktív témák
-
HARDVERAPRÓD
(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!
- 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
- Samsung 980 250Gb-os Nvme SSD csak kipróbált.
- Startech S2510BMU33 2.5" külső SATA SSD/HDD ház - Dobozos, újszerű
- Samsung 850 PRO 2TB V-NAND SSD, AAM számla, 1 év garancia
- SK Hynix Platinum P41 2 TB M.2 NVME PCI-E 4.0 x4 - Új, Tesztelt - 7000-6500 MBs - Eladó!
- RaidSonic IB-G226L-C31 - Dobozos, újszerű