-
Fototrend
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
-
Raymond
félisten
Valamit tuti maskepp csinal mert ujrafutotam az SSD-ken es igy nez ki:
Samsung 970 EVO 1TB: 4.9MB/s
Crucial MX300 750GB: 32.3MB/s
Crucial m4 512GB: 10.2MB/s
Crucial MX200 500GB: 14.7MB/sAz az MX300 pedig igy nez ki ATTO alatt:
[ Szerkesztve ]
Privat velemeny - keretik nem megkovezni...
-
vlac99
kezdő
válasz Raymond #38251 üzenetére
"Valamit tuti maskepp csinal "
Igen, mert az atto szekvenciális írást tesztel kikapcsolt ssd cache-sel.
fio pedig bekapcsolt cache-sel random szinkron irás blokkonként.Itt egy wdred 6TB-os hagyományos lemez ATTO tesztje 4k IOPS: 35000.
Ez a szekvenciális 4k irás, ugyanannyi mint a lemez max irási sebessége 150 MB/s.
Random 4K iops meg jónak számít 200 a HDD-knél.[ Szerkesztve ]
-
Raymond
félisten
válasz vlac99 #38252 üzenetére
"fio pedig bekapcsolt cache-sel random szinkron irás blokkonként."
Es ez mire lesz jo? Mert valos eletben nemigen tudok olyan felhasznalasrol ahol egy MX300 jobb megoldas lenne mint egy 970 EVO es a te tesztedbol megis ez jon le.Privat velemeny - keretik nem megkovezni...
-
vlac99
kezdő
Köszi egyébként a méréseket, remélem lesz még, virtuális gépekhez, kis sql szerverekbe számít a 4k random.
Egyre olcsóbbak a DC ssd-k , de azért 3-4 db -nál már számít az ár, otthoni vagy soho gépekhez, freenas-hoz zil lognak, stb.Úgy néz ki a legjobb jelenleg ebben a szegmensben, legalábbis sebességre a
Patriot Viper VPN100 512GB: 73,6MB/s
ADATA SX8200 PRO 256 GB: 71.4MB/s
Crucial MX300 750GB: 32.3MB/s[ Szerkesztve ]
-
vlac99
kezdő
válasz Raymond #38254 üzenetére
"valos eletben nemigen tudok olyan felhasznalasrol"
Pl.: ZFS ZIL/Slog (proxmox, freenas) , SQL szerver 16 KB-os blokkméretéhez. VM-ek,
nem akarsz enterprise ssd-t. 70 MB/s már ott is jó.970 EVO-ról nem tudok mit mondani miért ilyen a sebessége, de a fenti alkalmazásokhoz nem jó a teszt alapján, tudom meglepő, de jobb egy ADATA SX8200 PRO . Videoszerkesztés és hasonlók megint más dolog. Ez most a másik oldal, a sok kicsi blokk.
[ Szerkesztve ]
-
Raymond
félisten
válasz vlac99 #38255 üzenetére
"virtuális gépekhez, zil loghoz , kis sql szerverekbe számít a 4k random"
Igen, de te nem azt nezed ezzel a teszt-el. Van olyan erzesem hogy valami olyasmit tesztelsz aminem igazan fontos itt mert mas layer-ben van megoldva a dolog es nem ott ahol nezed. Egyebkent mindegy milyen bs ertekkel futtatom a tesztet, a 970 EVO-nal 1000-1200 koruli a write IOps csak a meret valtoztatasaval termeszetesen mas az MB/s ertek (es a teszt futtatasi ideje).Privat velemeny - keretik nem megkovezni...
-
vlac99
kezdő
válasz Raymond #38257 üzenetére
Úgy látom ez az EVO teszt nagyon nem tetszik neked. Nekem is nagyon alacsonynak tűnik, kellene egy másik teszt is belőle, de pont emiatt kértelek benneteket erre a tesztre, hogy lássak több ssd-t.
Az a tapasztalat, hogy ez a fio teszt pontosan megmutatja, hogy hogyan fog viselkedni például zil/slog- ként az adott ssd.Akkor egy másik konkrét mérés freenassal, dd-vel:
6db 2.7 TB lemez, ssd zil/slog, raidZ2( raid6):A freenas sebessége (nem az ssd-é) dd vel mérve:
szinkronizálás mindig:
Samsung 860 EVO : 17 MB
Intel DC S3700 : 77 MBNincs okom feltételezni, hogy a többi ssd-nél másképp alakulna, és nem a fio teszt szerinti
végeredményt kapnám.**************************************************************************
részletesen:
zfs set sync=always T6ZFSR2
root@nas:/mnt/T6ZFSR2/mentes # dd if=/dev/zero of=testfile_3 bs=16k count=50 000
50000+0 records in
50000+0 records out
819200000 bytes transferred in 46.166388 secs (17 744 511 bytes/sec)root@nas:/mnt/T6ZFSR2/mentes # zfs set sync=always T6ZFSR2
root@nas:/mnt/T6ZFSR2/mentes # dd if=/dev/zero of=testfile_2 bs=16k count=50 000
50000+0 records in
50000+0 records out
819200000 bytes transferred in 10.576980 secs (77 451 218 bytes/sec)[ Szerkesztve ]
-
Frawly
veterán
válasz Raymond #38257 üzenetére
Így van. Szervereknél, mikor sok kis random lemezművelet van, azokat a szoftver is már kötegelni szokta, akkor van nagy queue depth és thread szám. Tehát nem egyenként füstölteti az SSD ezért a NAND-ot, hanem kötegelve, párhuzamosítva + triple cache-eléssel történik (OS cache, esetleg egyéb szoftveres cache, SSD DRAM cache, NAND cache).
4KQ1T1-ben minden SSD lassú, még a csúcs NVMe-k sem nagyon hoznak 70-100 MB/sec-nél többet. Meg a sok kis random írás az a műfaj, ahol már a proci, RAM órajel, meg sok minden más is számít.
A fio össze-vissza mér mindent. Kezdjük ott, hogy ha tényleg cache-elt random írást mérni, akkor ilyen min. 200 MB/sec körül kéne indulnia a számoknak, ahogy az ATTO is csinálja, meg a CDM. Ugyanis az SSD a cache-elt random írást pont azért gyűjti be a cache-be, hogy aztán onnan kvázi szekvenciálisan írja ki.
[ Szerkesztve ]
-
Raymond
félisten
válasz vlac99 #38262 üzenetére
"Ezt próbáltam kideríteni"
Nem igazan, legalabbis nem azzal a parancsal amit hasznaltal. Erre ott a sima CDM, barmelyik SSD amit teszteltem jo lenne amire neked kell sebesseg szempontjabol* mert kb ez a helyzet ott:Samsung 970 EVO 1TB: 170-180MB/s
Crucial MX300 750GB: 130-140MB/s
Crucial m4 512GB:110-130MB/s
Crucial MX200 500GB:110-130MB/s
* amire kell arra inkabb azt neznem az SSD-n van-e valamilyen power loss protection. A Crucial-nal jellemzoen van, de nem kovetem tuzetesebben ezt mar egy ideje.Privat velemeny - keretik nem megkovezni...
-
-
vlac99
kezdő
válasz Frawly #38260 üzenetére
A fio össze-vissza mér mindent. Kezdjük ott, hogy ha tényleg cache-elt random írást mérni, akkor ilyen min. 200 MB/sec körül kéne indulnia a számoknak, ahogy az ATTO is csinálja, meg a CDM. Ugyanis az SSD a cache-elt random írást pont azért gyűjti be a cache-be, hogy aztán onnan kvázi szekvenciálisan írja ki.
Párszor leírtam, nem a cache-elt írás , nem a szekvenciális irás érdekelt, hanem az azonnali, blokkonkénti szinkron írás, ezért az --fsync=1. Ha ezt elhagyod a végéről mindjárt magkapod a 200 MB/sec körüli értéket. De engem most nem ez érdekelt, hanem hogy a kerti ssd-knek milyen a sebessége ilyen feltételekkel. Ebből következtetek pl. hogy mennyire lesz jó ZIL/SLOG-nak. De leragadtunk a 970 evonál, ami most nem a legjobban szerepelt. De mi van ha mégis csak ezt tudja ? Mitől tud ADATA 70 MB/sec-et, vagy S3700 50 MB/sec-et ?
Ugyanez a teszt. -
bpx
őstag
válasz vlac99 #38265 üzenetére
Ez azért nem ilyen egyszerű, ez a fájlrendszeren is múlik.
Intel 660p 2TB Windows-on, NTFS:
C:\Temp>fio --name=ssdtest --filename=test --size=100M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | findstr WRITE
WRITE: bw=61.3MiB/s (64.3MB/s), 61.3MiB/s-61.3MiB/s (64.3MB/s-64.3MB/s), io=100MiB (105MB), run=1632-1632msecADATA UE700 Pro 256GB pendrive, exFAT:
D:\>fio --name=ssdtest --filename=test --size=100M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | findstr WRITE
WRITE: bw=14.2MiB/s (14.9MB/s), 14.2MiB/s-14.2MiB/s (14.9MB/s-14.9MB/s), io=100MiB (105MB), run=7029-7029msecHa ugyanezt a pendrive-ot átdugom a Linuxos gépbe:
[root@r5 ~]# tail -10 /var/log/messages
Sep 20 22:49:36 r5 kernel: usb 4-1: SerialNumber: 298161509055008C
Sep 20 22:49:36 r5 kernel: usb-storage 4-1:1.0: USB Mass Storage device detected
Sep 20 22:49:36 r5 kernel: scsi host15: usb-storage 4-1:1.0
Sep 20 22:49:37 r5 kernel: scsi 15:0:0:0: Direct-Access ADATA USB Flash Drive 1100 PQ: 0 ANSI: 6
Sep 20 22:49:37 r5 kernel: sd 15:0:0:0: [sdh] 484966400 512-byte logical blocks: (248 GB/231 GiB)
Sep 20 22:49:37 r5 kernel: sd 15:0:0:0: Attached scsi generic sg7 type 0
Sep 20 22:49:37 r5 kernel: sd 15:0:0:0: [sdh] Write Protect is off
Sep 20 22:49:37 r5 kernel: sd 15:0:0:0: [sdh] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Sep 20 22:49:37 r5 kernel: sdh: sdh1
Sep 20 22:49:37 r5 kernel: sd 15:0:0:0: [sdh] Attached SCSI removable disk
[root@r5 ~]# mkdir /pen
[root@r5 ~]# mkfs.xfs /dev/sdh1 -f
meta-data=/dev/sdh1 isize=512 agcount=4, agsize=15155136 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=0, sparse=0
data = bsize=4096 blocks=60620544, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal log bsize=4096 blocks=29599, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
[root@r5 ~]# mount /dev/sdh1 /pen/
[root@r5 ~]# fio --name=ssdtest --filename=/pen/test --size=100M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | grep WRITE | awk '{ print $1 $2 }'
WRITE:bw=2283KiB/s
[root@r5 ~]# umount /pen/
[root@r5 ~]# mkfs.vfat /dev/sdh1
mkfs.fat 3.0.20 (12 Jun 2013)
[root@r5 ~]# mount /dev/sdh1 /pen/
[root@r5 ~]# fio --name=ssdtest --filename=/pen/test --size=100M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | grep WRITE | awk '{ print $1 $2 }'
WRITE:bw=6013KiB/s
[root@r5 ~]# mkfs.vfat /dev/sdh1 -S 4096
mkfs.fat 3.0.20 (12 Jun 2013)
[root@r5 ~]# mount /dev/sdh1 /pen/
[root@r5 ~]# fio --name=ssdtest --filename=/pen/test --size=100M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | grep WRITE | awk '{ print $1 $2 }'
WRITE:bw=14.8MiB/s
[root@r5 ~]#Tehát még ugyanazzal a fájlrendszerrel is más eredményeket ad, opcióktól függően.
Közben pl. Linuxon XFS-sel más SSD-k:
(Samsung 850 EVO, 970 EVO, XP941, Crucial BX100, centos_r5 = Kingston V300)[root@r5 ~]# vgs | grep -E "(evo|bx|941|centos)"
850evo 1 9 0 wz--n- 931.52G 357.52G
970evo1 1 19 0 wz--n- 931.52G 157.52G
970evo2 1 19 0 wz--n- 931.52G 157.52G
bx100 1 9 0 wz--n- 931.52G 357.52G
centos_r5 1 3 0 wz--n- <110.59g <61.59g
xp941 1 4 0 wz--n- <476.94g <276.94g
[root@r5 ~]# lvcreate -L 2G 850evo -n test
Logical volume "test" created.
[root@r5 ~]# lvcreate -L 2G 970evo1 -n test
Logical volume "test" created.
[root@r5 ~]# lvcreate -L 2G bx100 -n test
Logical volume "test" created.
[root@r5 ~]# lvcreate -L 2G centos_r5 -n test
Logical volume "test" created.
[root@r5 ~]# lvcreate -L 2G xp941 -n test
Logical volume "test" created.
[root@r5 ~]# mkdir /test_850evo /test_970evo /test_bx100 /test_xp941 /test_v300
[root@r5 ~]# mkfs.xfs /dev/mapper/850evo-test >/dev/null 2>&1
[root@r5 ~]# mkfs.xfs /dev/mapper/970evo1-test >/dev/null 2>&1
[root@r5 ~]# mkfs.xfs /dev/mapper/bx100-test >/dev/null 2>&1
[root@r5 ~]# mkfs.xfs /dev/mapper/xp941-test >/dev/null 2>&1
[root@r5 ~]# mkfs.xfs /dev/mapper/centos_r5-test >/dev/null 2>&1
[root@r5 ~]# mount /dev/mapper/850evo-test /test_850evo
[root@r5 ~]# mount /dev/mapper/970evo1-test /test_970evo
[root@r5 ~]# mount /dev/mapper/bx100-test /test_bx100
[root@r5 ~]# mount /dev/mapper/xp941-test /test_xp941
[root@r5 ~]# mount /dev/mapper/centos_r5-test /test_v300
[root@r5 ~]# [root@r5 ~]# fio --name=ssdtest --filename=/test_850evo/test --size=100M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | grep WRITE | awk '{ print $1 $2 }'
WRITE:bw=2189KiB/s
[root@r5 ~]# fio --name=ssdtest --filename=/test_970evo/test --size=100M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | grep WRITE | awk '{ print $1 $2 }'
WRITE:bw=1203KiB/s
[root@r5 ~]# fio --name=ssdtest --filename=/test_bx100/test --size=100M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | grep WRITE | awk '{ print $1 $2 }'
WRITE:bw=1221KiB/s
[root@r5 ~]# fio --name=ssdtest --filename=/test_xp941/test --size=100M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | grep WRITE | awk '{ print $1 $2 }'
WRITE:bw=1355KiB/s
[root@r5 ~]# fio --name=ssdtest --filename=/test_v300/test --size=10M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | grep WRITE | awk '{ print $1 $2 }'
WRITE:bw=489KiB/s
[root@r5 ~]#Persze ide is lehet VFAT-ot csinálni és akkor majd itt is tud ilyet:
[root@r5 ~]# umount /test*
[root@r5 ~]# mkfs.vfat /dev/mapper/850evo-test >/dev/null 2>&1
[root@r5 ~]# mkfs.vfat /dev/mapper/970evo1-test >/dev/null 2>&1
[root@r5 ~]# mkfs.vfat /dev/mapper/bx100-test >/dev/null 2>&1
[root@r5 ~]# mkfs.vfat /dev/mapper/xp941-test >/dev/null 2>&1
[root@r5 ~]# mkfs.vfat /dev/mapper/centos_r5-test >/dev/null 2>&1
[root@r5 ~]# mount /dev/mapper/850evo-test /test_850evo
[root@r5 ~]# mount /dev/mapper/970evo1-test /test_970evo
[root@r5 ~]# mount /dev/mapper/bx100-test /test_bx100
[root@r5 ~]# mount /dev/mapper/xp941-test /test_xp941
[root@r5 ~]# mount /dev/mapper/centos_r5-test /test_v300
[root@r5 ~]# fio --name=ssdtest --filename=/test_850evo/test --size=1000M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | grep WRITE | awk '{ print $1 $2 }'
WRITE:bw=82.4MiB/s
[root@r5 ~]# fio --name=ssdtest --filename=/test_970evo/test --size=1000M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | grep WRITE | awk '{ print $1 $2 }'
WRITE:bw=121MiB/s
[root@r5 ~]# fio --name=ssdtest --filename=/test_bx100/test --size=1000M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | grep WRITE | awk '{ print $1 $2 }'
WRITE:bw=72.8MiB/s
[root@r5 ~]# fio --name=ssdtest --filename=/test_xp941/test --size=1000M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | grep WRITE | awk '{ print $1 $2 }'
WRITE:bw=90.5MiB/s
[root@r5 ~]# fio --name=ssdtest --filename=/test_v300/test --size=1000M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | grep WRITE | awk '{ print $1 $2 }'
WRITE:bw=51.6MiB/s
[root@r5 ~]#Vagy journal nélküli ext4-et:
[root@r5 ~]# umount /test*
[root@r5 ~]# mkfs.ext4 -O ^has_journal /dev/mapper/850evo-test >/dev/null 2>&1
[root@r5 ~]# mkfs.ext4 -O ^has_journal /dev/mapper/970evo1-test >/dev/null 2>&1
[root@r5 ~]# mkfs.ext4 -O ^has_journal /dev/mapper/bx100-test >/dev/null 2>&1
[root@r5 ~]# mkfs.ext4 -O ^has_journal /dev/mapper/xp941-test >/dev/null 2>&1
[root@r5 ~]# mkfs.ext4 -O ^has_journal /dev/mapper/centos_r5-test >/dev/null 2>&1
[root@r5 ~]# mount /dev/mapper/850evo-test /test_850evo
[root@r5 ~]# mount /dev/mapper/970evo1-test /test_970evo
[root@r5 ~]# mount /dev/mapper/bx100-test /test_bx100
[root@r5 ~]# mount /dev/mapper/xp941-test /test_xp941
[root@r5 ~]# mount /dev/mapper/centos_r5-test /test_v300
[root@r5 ~]# fio --name=ssdtest --filename=/test_850evo/test --size=1000M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | grep WRITE | awk '{ print $1 $2 }'
WRITE:bw=65.2MiB/s
[root@r5 ~]# fio --name=ssdtest --filename=/test_970evo/test --size=1000M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | grep WRITE | awk '{ print $1 $2 }'
WRITE:bw=101MiB/s
[root@r5 ~]# fio --name=ssdtest --filename=/test_bx100/test --size=1000M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | grep WRITE | awk '{ print $1 $2 }'
WRITE:bw=58.6MiB/s
[root@r5 ~]# fio --name=ssdtest --filename=/test_xp941/test --size=1000M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | grep WRITE | awk '{ print $1 $2 }'
WRITE:bw=69.5MiB/s
[root@r5 ~]# fio --name=ssdtest --filename=/test_v300/test --size=1000M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | grep WRITE | awk '{ print $1 $2 }'
WRITE:bw=45.3MiB/s
[root@r5 ~]#Crucial MX100, Linux + ext4:
[root@obsidian ~]# cd /home/
[root@obsidian home]# mount | grep home
/dev/mapper/fedora_obsidian-home on /home type ext4 (rw,relatime,seclabel)
[root@obsidian home]# fio --name=ssdtest --filename=testfile1 --size=100M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | grep WRITE | awk '{ print $1 $2 }'
WRITE: bw=375KiB/sTök ugyanaz az SSD, ugyanabban a gépben, csak Windows + NTFS:
E:\>fio --name=ssdtest --filename=test --size=100M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 | findstr WRITE
WRITE: bw=8276KiB/s (8475kB/s), 8276KiB/s-8276KiB/s (8475kB/s-8475kB/s), io=100MiB (105MB), run=12373-12373msecSzóval akkor mit hasonlítunk mivel?
Egyébként nekem a fenti 5 SSD-n van általában 10-20-30 VM, abból, 10-20- ban vannak Oracle adatbázisok. Teljesen jó, de igazából egyikben sem történik semmi, egyszerre max 1-2 adatbázist hajtok meg tesztelésnél.
[ Szerkesztve ]
-
ledgeri
nagyúr
válasz Laccoss #38225 üzenetére
Ilyenkor hivatalosan csak a 0-ról újra játszik?
Alapból bonyolultabb, mint a IDE-s HDD-ről AHCI-s SSD-re váltás?// #ublockO-HardMode // anti-blockadblock-er // PH! új arculat: 1/ 500 // szeksziboj -nálam van egy pirospontod! // Találtam sárga fényű lézert! (kézit, ceruzaelemest) https://youtu.be/XQnmMjYHgcM //
-
Pano
addikt
Sziasztok!
Szeretnélek titeket megkérdezni, hogy ez az érték egy m.2 ssd esetében, i5-6200U proci mellett mennyire mondható normálisnak?
Október vége felé le fog járni a garija az ssd-nek és ha esetleg nem oké akkor még kihasználva a garit rá nézetnék (néha kicsit lassabbnak érzem a rendszert, de lehet csak túl nagy a kontraszt az asztali pc és a noti között )
A teszt a gyártó saját progijával futott le. Élettartamra 94%-ot jelöl, a hosszú teszt okéra futott.Transcend 256GB TS256GMTS800
[ Szerkesztve ]
-
Frawly
veterán
válasz vlac99 #38265 üzenetére
De még mindig nem érted, hogy valós használat során nem lesz letiltva a cache. Még ilyen log szervereken sem. Amit mérsz így a fio-val, az a NAND nyers random sebessége, meg esetleg a DRAM cache hiánya. De nem véletlen raknak mellé extra NAND cache-t, meg a vezérlőn is sok múlik.
-
Wyll
őstag
Ügyfél Asus Zenbook UX32A ultrabookjának upgrade-je van terítéken.
A 4GB ram 8GB-ra bővítése mellett a HDD-t is lecseréltük egy Crucial MX500-as, 500GB-os SSD-re.Ha láttok bármi rendellenességet, megköszönném, ha jeleznétek
[ Szerkesztve ]
Megbízhatóságom: http://phmegbizhatosag.atw.hu/phtabla.php?nev=Wyll
-
Frawly
veterán
válasz vlac99 #38279 üzenetére
Elhiszem neked, de azt kell érteni, hogy ennek nincs értelme. A szinkron írás eredetileg azért van, hogy ne legyen adatvesztés, hanem azonnal kimenjen a háttértárra az adat. De ahol ez fontos tényező, szerveren, ott van szünetmentes táp, nem fog elmenni az áram, amíg a cache kiíródik aszinkron módon. Ezeket az írásokat az OS-re kell bízni, meg az SSD vezérlőjére, nem javasolt azoknál „jobban tudni” vagy „jobban érteni” hozzá. Pont így szoktak a nem szabványos szoftveres gányolások születni, mikor valaki jobban tudja a tutit mindenkinél, megkerülve sztenderd eljárásokat, és később meg a szenvedés van miatta, mikor másik platformra kéne portolni vagy emulálni/virtualizálni kéne.
Ez az egyenkénti 16 KB blokkírás eleve rontja az írásteljesítményt (elég csak ezeket a beírt benchmarkeredményeket megnézni 4-70 MB/sec vs. 180-300 MB/sec), meg hosszú távon árt az SSD-nek is. Biztos vagyok benne, hogy valahogy ZFS-nél is beállítható, hogy aszinkron, cache-eléssel logoljon.
Arról nem is beszélve, hogy ma már a legtöbbször szervert virtualizálva és/vagy cloudban futtatnak, ahol megint nem játszik a szinkron írás, nem tudsz beleirkálni a köztes réteg miatt közvetlenül a NAND-ba.
Ha ilyen egyenkénti 16 KB blokkos írással akarsz nagy teljesítményt, akkor Intel Optane SSD vegyél. Előre szólok, hogy méreg drága, még a jobbfajta NVMe-khez képest is, nem hogy azokhoz a SATA-sokhoz képest, amiket te fio-zol.
-
vlac99
kezdő
válasz Frawly #38283 üzenetére
Pont így szoktak a nem szabványos szoftveres gányolások születni, mikor valaki jobban tudja a tutit mindenkinél, megkerülve sztenderd eljárásokat, és később meg a szenvedés van miatta, mikor másik platformra kéne portolni vagy emulálni/virtualizálni kéne.
mikor valaki jobban tudja a tutit mindenkinél,
ok.
MYSQL sját dokumentációjaából kis részlret:
[link]" Az InnoDB az adatfájlokat 16 KB-os oldalakban kezeli
fontos, hogy a ZFS rekordméretet az adatoldalak méretének megfelelőre állítsa. Ezt be kell állítani, mielőtt bármilyen fájlt létrehozna a köteten, és a beállító parancs így néz ki:# zfs állományméret = 16K zp1 / adat"
MI a megoldás,milyen ssd-t javasolsz , ami nem optane , vagy nem intel PMM.. Nincs rá most 7000 dollárom. (Tankolnom kell e JET-be is...)
[ Szerkesztve ]
-
Raymond
félisten
válasz vlac99 #38284 üzenetére
Ahogy mar irtam a ZIL/SLOG drive-nal elsosorban azt nezd hogy van-e power loss protection, utanna elmeletileg nezheted az irasi sebesseget, de nem ertem minek amikor a legjobb megoldasok erre (Intel DC es Optane) bagoert vannak. Egy 16GB vagy 32GB Optane ujonnan is 30-50EUR es ha olyan a rendszer hogy nem lenne eleg egy 32GB ZIL/SLOG SSD akkor eleve ne nezegess konzumer SSD-ket.
Privat velemeny - keretik nem megkovezni...
-
vlac99
kezdő
válasz Raymond #38285 üzenetére
akkor eleve ne nezegess konzumer SSD-ket.
Kösz a konstruktív hozzáállást.
SEHOL nem írtam, hogy mire akarom használni., Ketten dobtátok be, hogy a fio hülyeség, , nem kell szinkron írás, arra van a szünetmentes, 16 KB blokkméret az meg minek? (egyébként azért kell, hogyaz sql jellegzetességéből adódóan minél gyorsabban lehessen olvasni, nem pedig az írás miatt ) A szinkron irás meg azért, hogy h a egy alkalmazás biztos lehessen benne , hogy az adatok lemezen vannak..
PLP nem kérdeztem , de jópáran, : a samsung is árul power loss nélküli DC(T) ssd-ket. .a 70 MB/Sec, amit némelyik consumer ssd tud az 17500 IOPs , nemrossz ebben műfajban.
használtan ebay-en kapsz 80 dollárért intel DC s3700vagy duplájáért p3700 DC-t. -
Frawly
veterán
De azt nem érted, hogy az alkalmazásnak nem kell biztosabbnak lennie az írást illetően, mint az OS-nek. Nem véletlenül vannak benne az OS-ben az absztrakciós rétegek. Ez már nem a 80-as évek, ahol DOS alatt muszáj volt kiírni mindent, hogy biztosan a lemezen legyen, és közvetlenül elérni a hardvert. Mind az SSD-be, mind a modern OS-ekbe, mind a modern fájlrendszerekbe van beépítve mechanizmus adatvesztés és power loss ellen.
Ez a 16 KB-os blokkokban írás is hülyeség, még egyenkénti írásban is, mivel a legújabb QLC-s SSD-k már 32 KB-os blokkmérettel rendelkeznek, meg törlésnél nem is lehet blokkot törölni, csak egy egész lapot, ami meg több megás. Sőt, az NVMe protokoll is arra épül, hogy minél több lemezműveletet lehessen párhuzamosítani és sorba állítani, ha elkezdesz egyenként írogatni, akkor elveszted ezt az előnyt.
Konzumer SSD-knél a legjobb, amit vehetsz, az a Samsung 970 Pro. Drága, de még megfizethető, ettől nincs gyorsabb. Vagyis vannak már PCIe 4.0-ás SSD-k, de azok is max. szekvenciálisan nincsenek a PCIe 3.0 által korlátozva, random lemezműveletekben azok sem gyorsabbak a 970 Pro-nál.
SATA-sban a leggyorsabb a 860 Pro, de az majdnem annyiba kerül, mint az NVMe-sek. Az s3700-at ismerem, de azt nem tudom, hogy a p-s miben különbözik. Utánanézhetnék, de olyan mélyen nem érdekel, nem tervezek ilyet venni, és a topikban sem nagyon keresnek ilyen felhasználásra SSD-t.
-
ledgeri
nagyúr
válasz Laccoss #38270 üzenetére
Még egy kérdés a témában:
NVMe-ről NVMe-re való klónozásnál van-e valami akadály, vagy az már normál, pl macrium intézi?
NVMe-ről vissza AHCI-re igy ugyanúgy bukó...? gondolom...// #ublockO-HardMode // anti-blockadblock-er // PH! új arculat: 1/ 500 // szeksziboj -nálam van egy pirospontod! // Találtam sárga fényű lézert! (kézit, ceruzaelemest) https://youtu.be/XQnmMjYHgcM //
-
Frawly
veterán
válasz ledgeri #38288 üzenetére
Az NVMe-ről NVMe-re klónozásnak nincs specialitása, Macriumnak hibátlanul meg kéne csinálnia. Elvileg NVMe-AHCI irányba is megy, oda-vissza. Egyedül akkor van az AHCI telepítés klónozásával baj, ha Legacy BIOS / MBR partíciós táblás boottal lett telepítve, amit az NVMe nem támogat (annál kötelező a GPT partíciós tábla és UEFI boot, ha bootolni is akarsz róla).
[ Szerkesztve ]
-
ledgeri
nagyúr
válasz Frawly #38289 üzenetére
Ohh, ez így más perspektíva!
Ha nulláról telepítek "friss" hardverekkel (b450 chipset, pl 860 evo), akkor esek-e el bármitől ha GPT és UEFI kerül kiválasztásra?
Kell-e könnyíteni jövő-magamnak, vagy reinstall és kész... úgy is "jó ha néha megesik egy friss install"?// #ublockO-HardMode // anti-blockadblock-er // PH! új arculat: 1/ 500 // szeksziboj -nálam van egy pirospontod! // Találtam sárga fényű lézert! (kézit, ceruzaelemest) https://youtu.be/XQnmMjYHgcM //
-
Frawly
veterán
válasz ledgeri #38290 üzenetére
Nem esel el semmitől. Egyedül Legacy OS nem fog tudni bootolni arról a meghajtóról (XP és attól régebbi), de nem hinném, hogy B450 chipsetes gépen ilyet terveznél. NVMe-nél nincs is más választásod, csak UEFI boot + GPT jön szóba.
De UEFI bootot egyébként is megéri használni, felgyorsíthatja a lemezek detektálását és booteszközök, OS-ek keresését, ezzel pedig egyes lapokon lehet nyerni 1-2 másodpercet is bootoláskor, néha akár többet is. Vagyis nem magát a bootolást gyorsítja fel, hanem a bootolás előtti időt, amit a gép az UEFI BIOS fázisnál tölt el.
-
ledgeri
nagyúr
-
Frawly
veterán
válasz ledgeri #38292 üzenetére
Igen, elégnek kéne lennie. Veszteni valód amúgy sincs, legrosszabb esetben csak nem fog bootolni a klónozott rendszer vagy nem probléma nélkül. Elrontani nem tudod, legfeljebb ha nem sikerül, klónozod még egyszer.
Esetleg még ha először nem bootolna, akkor próbáld kivenni a régi NVMe SSD-t. A Windowst vagy az UEFI BIOS-t lehet zavarni fogja, hogy két különböző lemezen is ugyanaz az UUID-jű partíció van, de ez is csak egy elég elméleti lehetőség.
[ Szerkesztve ]
-
Kékes525
félisten
Nem értem a Samsung Magican (6.0) és a Windows 10-et (1903).
1. Miért javasolják az SSD töredezésmentesítését? [kép] , [kép]
2. Másrészt az I meghajtó nem merevlemez, hanem SSD (Samsung SSD 850 PRO 256GB)
Az első ("C" a rendszer meghajtó, míg az "I" meghajtó USB3-ra van dugva.
A rendszer SSD-nek Samsung NVMe Controller (PCI\CC_010802) [VEN: 144D, DEV: A804] Verzió: 3.1.0.1901, 1-17-2019 drivere van.
Az "I" megajtónak Intel(R) USB 3.0 eXtensible Host Controller - 1.0 (Microsoft) (USB 3.0) [VEN: 8086, DEV: A2AF] Verzió: 10.0.18362.207, 6-19-2019" drivere van.[ Szerkesztve ]
Minden számítógép füsttel működik, ha kimegy belőle, akkor nem működik.
Ú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
- Milyen okostelefont vegyek?
- Politika
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- BestBuy topik
- Luck Dragon: Asszociációs játék. :)
- Suzuki topik
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Milyen cserélhető objektíves gépet?
- Milyen routert?
- További aktív témák...