Hirdetés
- Szólánc.
- Asszociációs játék. :)
- Fűzzük össze a szavakat :)
- Egy korszak vége
- Ingyen kellene, de tegnapra
- CTEK akkumulátor töltő és másolatai
- Elektromos rásegítésű kerékpárok
- eBay-es kütyük kis pénzért
- i5 12400F - báránybőrbe bújt farkas
- Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
-
LOGOUT.hu
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
-
p.lac
tag
-
p.lac
tag
Idézetek másoktól: link
Windows 8 gyorsindítás:
"A gyorsindítás használatakor a számítógép gyorsabban indul el leállítás után. Ehhez a Windows a számítógép kikapcsolásakor egy fájlba menti a rendszer-információkat. Amikor legközelebb bekapcsolja a számítógépet, a Windows nem újraindítja, hanem (a mentett rendszer-információkat használva) folytatja a számítógép futtatását."
"Elképesztő a Windows 8 gyorsasága. Miközben a Core i3 2,2GHz-es laptop 6GB rammal a Win7 kb 1-1,5perc alatt állt fel teljesen, a Win8 maximum fél perc.
A lapozófájl is felesleges volt számomra így azt kikapcsoltam.
De egy 40GB-os partíción miért csak 8GB hely maradt? " -
p.lac
tag
válasz
FollowTheORI
#14948
üzenetére
"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."
Egyetértek.
"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)."
Szerintem Trimmel sokkal kevésbé fordulhat elő.
"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."
és
"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)."
Egyetértek.
-
p.lac
tag
-
p.lac
tag
válasz
janos666
#14940
üzenetére
Elnézésedet kérem, nem voltam elég figyelmes, az általad írtak nem álltak ellentmondásban a linkelt cikk idézett részével.
Viszont ennek az állításodnak egy részével vitáznék, hátha okosabb leszek tőle:
"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."
Úgy tudom, hogy ha Trimmelünk, akkor a Garbage Collector nézi, hogy melyik blokkban van törlendő page, és ebből a blokkból (A blokk) átmásolja az érvényes adatokat a (B) üres blokkba, majd törli az (A) blokkot. Ha van elég szabad hely és ügyes a vezérlő, akkor gondolom nem sieti el a törlést, mert lehet, hogy az (A) blokkból más page is törlésre kerül hamarosan, és akkor egy füst alatt elvégzi a fentieket, kevésbé terhelve így az SSD-t.
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). Itt olvastam erről.
-
p.lac
tag
válasz
janos666
#14925
üzenetére
Ne vedd kötekedésnek, de a Page méretek mellett volt még egy fontos állításbeli különbség:
"De egyrészt, amennyire én tudom (de javítsatok ki, ha tévedek - én elismerem, hogy előfordul) a legtöbb SSD nem 4k, hanem 8k "szektoros", mert 8k szokott lenni egy NAND Page (ami ha jól tudom azt jelenti, hogy ekkora egységekben írhat a vezérlő a NAND-ra, a 4k írást is vagy úgy oldja meg, hogy kiolvas 8k-t és visszaírja 4k-val módosítva, vagy alternatívaként összevár több 4k-s írást, mikor "ráér" és elfér a cache-ben)."
"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."
-
#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 ]
-
p.lac
tag
válasz
janos666
#14853
üzenetére
Elakadtam, a blkdiscard hibával elszáll:
[root@localhost /home/lac]# while IFS=: read -ra FREE; do echo blkdiscard --offset ${FREE[1]%%B} --length ${FREE[2]%%B} /dev/sda; done < <(parted -m /dev/sda unit b print free | grep ':free;')
blkdiscard --offset 32256 --length 1048575 /dev/sda
blkdiscard --offset 48485105664 --length 60022480895 /dev/sda
[root@localhost /home/lac]# blkdiscard --offset 48485105664 --length 60022480895 /dev/sda
blkdiscard: /dev/sda: BLKDISCARD ioctl failed: Érvénytelen argumentumEzt találtam blkdiscard forrásában:
if (ioctl(fd, BLKGETSIZE64, &blksize))
err(EXIT_FAILURE, _("%s: BLKGETSIZE64 ioctl failed"), path);
if (ioctl(fd, BLKSSZGET, &secsize))
err(EXIT_FAILURE, _("%s: BLKSSZGET ioctl failed"), path);Vagyis ha jól értem, akkor nem tetszik neki a tartomány (offset vagy length), pedig azt ugye B-ra pontosan megmondta a "parted -m /dev/sda unit b print free".
A man ezt mondja:
The offset and length arguments may be followed by the multiplicative suf‐
fixes KiB=1024, MiB=1024*1024, and so on for GiB, TiB, PiB, EiB, ZiB and YiB
(the "iB" is optional, e.g., "K" has the same meaning as "KiB") or the suf‐
fixes KB=1000, MB=1000*1000, and so on for GB, TB, PB, EB, ZB and YB.-o, --offset offset
Byte offset in the device from which to discard. Provided value will
be aligned to the device sector size. Default value is zero.-l, --length length
Number of bytes after starting point to discard. Provided value will
be aligned to the device sector size. If the specified value extends
past the end of the device, blkdiscard will stop at the device size
boundary. Default value extends to the end of the device.Vagyis elvileg el is hagyhatnám a --length-et, mert nekem a meghajtó végéig kell amúgy is discardolni, de inkább óvatos vagyok mert ugye a blkdiscard adatvesztéssel jár, így inkább kérdezek.
-
#14854
p.lac
tag
Atomnyuszi
#14852
p.lac
tag
válasz
Atomnyuszi
#14852
üzenetére
-
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.
-
p.lac
tag
Emperor_, janos666:
Köszönöm mindkettőtöknek.
Valóban, a DiskFresh utáni mérés 2MB-os blokkmérettel történt, míg az azt megelőző 4MB-ossal, de erre nem volt ráhatásom.
Többet is mértem DiksFresh után, de már kb. 4-5 nap használat után kapcsoltam, hogy kellene még mérni, és ezek között van 4MB-os blokkméretű is, ami már magasabb maximális olvasási értéket mutat, de még mindig (szerintem hibahatáron túli) az eltérés.
DiskFresh előtt:
DiskFresh után (4-5 napos használatot követően):
Valószínűleg beáldozok mindjárt még kb. 55GB-nyi írást és csinálok egy újabb DiskFresht, ha már ennyit bajlódunk vele.
[ Szerkesztve ]
-
p.lac
tag
Sziasztok!
Bő 1 éves használat után Kingston v300-as ssd-met diskfresh-eltem. Számomra érdekesek a grafikonok, ránéznétek?
Első telepítés előtt került kialakításra ez a kiosztás:
1 éves használat után:
DiskFresh után:
Windows boot idő: 16,64s -> 14,9s, 1,74s csökkenés (-10,5%)
Linux boot idő: 13,598s -> 12,793s, 0,805s csökkenés (-5,9%)DiskFresh után a minimális olvasási sebesség nőtt, ezt értem. Az átlagos olvasási sebesség is nőtt, ezt is értem. De miért csökkent a maximális olvasási sebesség DiskFresh után?
p.lac
-
#14835
p.lac
tag
Atomnyuszi
#14829
p.lac
tag
válasz
Atomnyuszi
#14829
üzenetére
Én ilyenről még nem hallottam, hogy ssd-vel rövidebb lenne az akkuidő, mivel általában az ssd fogyasztása jóval alacsonyabb a hdd fogyasztásánál. (Elhiszem a tapasztalatodat csak nem tudom az okát.)
Ú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
- AKCIÓ! 1TB Samsung 990 PRO NVMe SSD meghajtó garanciával hibátlan működéssel
- Garanciális! Samsung 990 PRO 1TB M.2 NVMe SSD
- AKCIÓ! 1TB Samsung 990 PRO NVMe SSD meghajtó garanciával hibátlan működéssel
- BESZÁMÍTÁS! 1TB Samsung 980 PRO NVMe SSD meghajtó garanciával hibátlan működéssel
- BESZÁMÍTÁS! 3TB Western Digital RED SATA HDD meghajtó garanciával hibátlan működéssel
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest