Linux за българи: Форуми

Хардуер за Линукс => Десктопи => Темата е започната от: Naka в Dec 11, 2019, 17:54



Титла: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: Naka в Dec 11, 2019, 17:54
На един клиентски компютър има SSD Samsung 840 Evo 120Gb. включен към sata3

Обаче винаги дава бавен трасфер от порядъка на 80mb/sec.
Тествах go със hdparm -tT /dev/sdb и dd if=/dev/sdb ..... последователно  четене, но резултата е винаги един и същ - 80Мb/sec.

В самсунг го дават R/w 540 Mb/sec / 410 MB/S долу горе колкото може да пусне сатата.
Аз ли нещо греша или нещо трябва да се включи в Bios-а или диска си е позаминал?

----
В bios-a сменях на IDE mode и AHCI mode - промяна никава. Пак стои на 80Mb/sec


Титла: Re: Бавен трансфер на SSD
Публикувано от: makeme в Dec 11, 2019, 18:46
Единствено се сещам да е от дъното. Другия вариант е диска да е fake.

това колко ти дава?
dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync && rm -fv test

smartctl-то пише ли някакви малки проценти живот?
ext4 ли е ?

PS:
на ADATA SU800, който уж е с dram и SLC cache в рамките на теста, ми дава:
Цитат
# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync && rm -fv test
16384+0 records in
16384+0 records out
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 4,65804 s, 231 MB/s

Предположението ми за fake се базира на това, че EVO-tata са TLC, а не QLC:
https://youtu.be/WACyyFF_ci0?t=830
Ако SSD-то e QLC, след кеша ще имаш тези скорости реално.

Според тази стадия до 3гб трябва да имаш скоростите, дето търсиш (R/w 540 Mb/sec / 410 MB/S) след dram-a:
https://techreport.com/review/25122/samsungs-840-evo-solid-state-drive-reviewed/


Титла: Re: Бавен трансфер на SSD
Публикувано от: Naka в Dec 11, 2019, 19:52
Пробвах го на друго дъно абсолютно същата работа. И факе дискове ли имало? Какво означава факе? Китаец дето се представя за оригинален самсунг?

Смарта каза че диска е на 25000 часа и има записани около 7 Tb... На тези eva дискове четох че им дават около  TBW 14 тб. Така че е на половината си живот


Може ли да пробваш hdparm -tT  /dev/sda... ....  На някой ssd? Командата е безопасна.


Титла: Re: Бавен трансфер на SSD
Публикувано от: makeme в Dec 11, 2019, 19:54
На същата adata:
Цитат
# hdparm -tT /dev/sdb1

/dev/sdb1:
 Timing cached reads:   14170 MB in  1.99 seconds = 7104.61 MB/sec
 Timing buffered disk reads: 492 MB in  3.02 seconds = 162.83 MB/sec

ПП: Имай предвид че с hdparm и дд винаги показва по-малко :) на windows с
https://crystalmark.info/en/software/crystaldiskmark/
хващат, колкото пише.


Титла: Re: Бавен трансфер на SSD
Публикувано от: Naka в Dec 11, 2019, 19:57
A hdparm -i /dev/....


Титла: Re: Бавен трансфер на SSD
Публикувано от: makeme в Dec 11, 2019, 19:58
Цитат
# hdparm -i /dev/sdb

/dev/sdb:

 Model=ADATA SU800, FwRev=Q0518BS, SerialNo=2H4620045478
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=unknown, MaxMultSect=2, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=250069680
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-4,5,6,7

 * signifies the current active mode
За fake предполагам само. Те братята китайци не спят :). Може и просто кеша да не е наред, не знам, но затова ти пратих клипчето. Просто си спомних, че някъде съм я виждал точно тази скорост.


Титла: Re: Бавен трансфер на SSD
Публикувано от: Naka в Dec 11, 2019, 21:19
Това за тези буфери 40Gb  не го знаех.
Аз изобщо не успях да го пробвам на запис.. Пробвах го само на четене, като за по лека и бърза операция... Обаче този трансфер 80 мб/сек ме учуди много.


А какво мислите за този диск?
https://www.vali.bg/bg/product/16874/Solid-State-Drive-(SSD)-Gigabyte-M.2-Nvme-PCIe-SSD-512GB

Някой работил ли е и има ли впечатления от дисковете на гигабайт?


Титла: Re: Бавен трансфер на SSD
Публикувано от: makeme в Dec 11, 2019, 21:36
Ми моето мислене за nvme-тата е малко снобско, но мисля че Evo-тата на самсунг са най добри (цена/качество). Да, малко по-скъпи са, но съм доволен.
Разбира се ако си правя бърза nvme флашка най-вероятно бих си взел по-евтин и бавен вариант.

ПП: Как така не си го пробвал на запис? dd, дето предложих има запис?


Титла: Re: Бавен трансфер на SSD
Публикувано от: jet в Dec 12, 2019, 02:24
* Колко пълен е този диск/партишън. Когато е много пълен диска се забавя.
* Трим-а разрешен ли е на ОС-а дето я търкаля?

* пусни му един
fstrim /мнт/диск
от твоя Линукс

* С друг кабел пробвал ли се?
* Качвай му нов firmware (Може да е от някоя проблемна партида)
"...Magician is the Samsung optimization and management tool for its hard drives, and includes firmware updates and other useful features for fixing bugs..."
https://www.samsung.com/semiconductor/minisite/ssd/download/tools/


Титла: Re: Бавен трансфер на SSD
Публикувано от: Naka в Dec 12, 2019, 12:08
* Колко пълен е този диск/партишън. Когато е много пълен диска се забавя.
* Трим-а разрешен ли е на ОС-а дето я търкаля?

* пусни му един
fstrim /мнт/диск
от твоя Линукс

Чак пък толкова от един непуснат трим да падне от 540мб/сек на 80 мб/сек :o :o :o Но е възможно изобщо да не бил пуснат (win7) защото  биоса беше на IDE а не на AHCI. Колегата тука разправя че за trim под виндовс трябвало AHCI ???
Диска е пълен на половина.
По скоро ми мяза на много стар модел/версия или бъгъв firmware.

Както и да е диска вече е при клиента и не мога да експериментирам. А и беше пълен с важна информация.



Титла: Re: Бавен трансфер на SSD
Публикувано от: Naka в Dec 13, 2019, 13:39
А какво мислите за този диск?
https://www.vali.bg/bg/product/16874/Solid-State-Drive-(SSD)-Gigabyte-M.2-Nvme-PCIe-SSD-512GB
Някой работил ли е и има ли впечатления от дисковете на гигабайт?

Друг варянт който ми се вижда хубав е 500GB SSD Kingston A2000
https://ardes.bg/komponenti/tvardi-diskove/kingston/kapatsitet-ot-257-do-525/m-2-2280/ssd-solid-state-drive

И цената евтина на кингстана 137лв. и бърз 2000/2000 и гаранция 5 год. Но това което му е малко е само 300 TBW.

Докато на Гигабайта му дават 800TBW :o Незнам да им вярвам ли или не. Никога не съм допирал до дискове на ГБ. А и нещо навсякъде в бг се ебават с гаранциите им - все ги пишат 3год (при този огромен TBW ???). Въпреки че в сайта на ГБ е  5 год или 800TBW.



Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: spec1a в Dec 14, 2019, 11:02
   Малко встрани от темата,тъй като имам малък опит със SSD дискове,
искам да попитам за какъв обем дисково пространство става дума ?
   GB или GiB ?
   Съгласно някакви нови стандарти 1 GB е 1000*1000*1000 байта,
а 1 GiB е 1024*1024*1024 байта.
   Горе се говореше за 500GB, въпроса е : 500GB или 500GiB ?
При класическите твърди дискове понякога производителите послъгват...
Маркетингови трикове ...


Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: makeme в Dec 14, 2019, 11:15
За МБ/ГБ става дума. Иначе за тоя маркетингов "стандарт" си прав. Повечето от  много отдавна така надписват продуктите си. За това и съм спрял да обръщам внимание.


Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: Naka в Dec 14, 2019, 11:24
Още един въпрос колко е голям сектора при SSD? 4096 ? Повечето нищо не казват по въпроса освен seagate. И какво е това 512e  ?

https://www.seagate.com/gb/en/tech-insights/advanced-format-4k-sector-hard-drives-master-ti/

Ако по default е 4096 това означава че например не може да се прехвърля (клонира) с dd между SDD и HDD щото е различен сектора 4096<-->512


Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: 4096bits в Dec 14, 2019, 13:03
Няма страшно. Харддисковете скоро няма да изчезнат.


Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: jet в Dec 14, 2019, 20:54
При мен:
HDD
   User Capacity:    6,001,175,126,016 bytes [6.00 TB] , 11721045168 sectors
Това се равнява на 5.47  TiB


SSD
   User Capacity:    480,103,981,056 bytes [480 GB], 937703088 sectors
Това се равнява на 447.13  GiB

И в двата случая производителите дават в GB а не GiB за съжаление



Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: Naka в Dec 14, 2019, 22:05
SSD
   User Capacity:    480,103,981,056 bytes [480 GB], 937703088 sectors

  Което прави 512 байтови сектори.


Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: go_fire в Dec 15, 2019, 13:01
   Малко встрани от темата,тъй като имам малък опит със SSD дискове,
искам да попитам за какъв обем дисково пространство става дума ?
   GB или GiB ?
   Съгласно някакви нови стандарти 1 GB е 1000*1000*1000 байта,
а 1 GiB е 1024*1024*1024 байта.
   Горе се говореше за 500GB, въпроса е : 500GB или 500GiB ?
При класическите твърди дискове понякога производителите послъгват...
Маркетингови трикове ...


А бе не знам, какво пишат и не пишат производителите, но GB трябва да е кратен на 1024 (по-точно осмична бройна система), a тази измишльотина GiB (integer?) може да си е хиляда или каквото си поиска.

Странно, че преди повече от десет години осъдиха всички производители в щатите за бая пари, но въпреки това продължават да „закръгляват“.


Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: remotexx в Dec 15, 2019, 18:22
Кратка историческа справка - истината е, че простолюдието си държи на своето, независимо колко е тъпо и колко противоречи на науката (аз затова препочитам ИИ)

1. Всеки ел. техник ше ви каже че тия означения - pico, nano, micro и нагоре kilo mega и пр. по стандарт (вкл. и международен) се изписват с малка буква - kV, mW, pF и т.н. те затова навремето по дисковете минаха на главни букви където вече К = 210 = 1024, М = 1024 * 1024 и т.н.

2. Според историческата наука декадите се именуват на завършващата година (имах много добър учител по история) напр. хх01 - хх10 са десетте години на века а хх91-хх00 са стоте години, ама нее простолюдието си твърди че 80-89 биле осемдесетте и в началото на века се умълчават щото хх00-хх09 им звучало кофти 'нулевите години' р'ииш ли  ???

та затова сега имаме k, K, Ki
че и с B се заиграха, вече има и KiBi, (битове вместо байтове - или octets - фр.)

нямам спомен дали се съдиха и ги осъдиха или производителите доброзорно смениха означенията, но фактът си е факт... ама някой ден ще остане само ИИ да си оправи ...държавиците. Аз откога разправям колко ще му е трудно да обясни нещо на простите ора защо не саправи и са в противоречие с науката (независмо че напр. не са политици и заплатата им /не/ зависи от това да /не/ го разберат) - и още има хора не дето не го вярват това че ще стане ама като гледам то вече е дошло това време...

ама иде видов ден.. доскоро беше ххх-ите на сапун, скоро ще стане, мани-мани пак хора (култов лаф от Планетата на маймуните) - на батерии (и то ако прецени /ИИ/ че има файда от цялата тая хамалогия да се разрпавя с прости хора)
имаше навремето един хубав филм по темата - 'История на света' където един човечец все повтаряше ' А бе некой трови водата на динозаврите - ще измрът' и накрая даже си призна че той е човекът и пак никаква реакция, динозврите си измряха... и другия култов лаф беше 'Да го духат бедните'
History of the World: Part I (1981)
https://www.imdb.com/title/tt0082517

П.П. Гога 1024 има толкова общо с осмичната колкото ис 16-тичната бройна система, по-скоро идва от двоичната - 2 на степен 10 = 1024 а и е близо до 1000 = 103 пък и 1024 ( 8 ) = 1*83 + 2*8 + 4 = 512 + 16 +4 = 532 (10) което не е близо до нищо кръгло (десетично) ...совен може бо до половинката на 1000 ама не е кръгло число, а и повечето хора не могат да смятат hex  ;D


Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: jet в Dec 15, 2019, 18:52
Абе важното е, че така производителите икономисват една плоча в HDD или един чип в SSD (при милиони бройки, това си е бонуса на CEO-то).
Сега такива дебати се водят и как да се мери пробега на EV-тата.


Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: Naka в Dec 28, 2019, 13:43
Взех Кинстана А2000 500GB (SA2000M8/500G)
Много хубаво дискче.

[root@sabi ~]# hdparm -tT /dev/nvme0n1

/dev/nvme0n1:                                                                                                                                       
Timing cached reads:   33010 MB in  1.99 seconds = 16610.08 MB/sec                                                                                 
Timing buffered disk reads: 5390 MB in  3.00 seconds = 1796.59 MB/sec                                                                             
[root@sabi ~]#


[root@sabi tmp]# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync && rm -fv test
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 0.925666 s, 1.2 GB/s
removed ‘test’
[root@sabi tmp]#

[root@sabi ~]# dd if=/dev/nvme0n1 of=/dev/null bs=65536
^C68215+0 records in                                                                                                                               
68214+0 records out                                                                                                                                 
4470472704 bytes (4.5 GB) copied, 2.44674 s, 1.8 GB/s                                                                                               
                                                                                                                                                   
[root@sabi ~]# 

[root@sabi tmp]# smartctl --all /dev/nvme0n1
smartctl 7.0 2018-12-30 r4883 [x86_64-linux-3.10.0-1062.9.1.el7.x86_64] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       KINGSTON SA2000M8500G
Serial Number:                      50026B7282536B1F
Firmware Version:                   S5Z42105
PCI Vendor/Subsystem ID:            0x2646
IEEE OUI Identifier:                0x0026b7
Controller ID:                      1
Number of Namespaces:               1
Namespace 1 Size/Capacity:          500,107,862,016 [500 GB]
Namespace 1 Utilization:            21,476,192,256 [21.4 GB]
Namespace 1 Formatted LBA Size:     512
Namespace 1 IEEE EUI-64:            0026b7 282536b1f5
Local Time is:                      Sat Dec 28 13:41:53 2019 EET
Firmware Updates (0x14):            2 Slots, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x005f):     Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat Timestmp
Maximum Data Transfer Size:         32 Pages
Warning  Comp. Temp. Threshold:     75 Celsius
Critical Comp. Temp. Threshold:     80 Celsius

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     9.00W       -        -    0  0  0  0        0       0
 1 +     4.60W       -        -    1  1  1  1        0       0
 2 +     3.80W       -        -    2  2  2  2        0       0
 3 -   0.0450W       -        -    3  3  3  3     2000    2000
 4 -   0.0040W       -        -    4  4  4  4    15000   15000

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         0

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        35 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    224,730 [115 GB]
Data Units Written:                 98,817 [50.5 GB]
Host Read Commands:                 2,049,934
Host Write Commands:                1,185,270
Controller Busy Time:               13
Power Cycles:                       24
Power On Hours:                     34
Unsafe Shutdowns:                   2
Media and Data Integrity Errors:    0
Error Information Log Entries:      0
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0

Error Information (NVMe Log 0x01, max 256 entries)
No Errors Logged

[root@sabi tmp]#


----
Обаче след fstrim -a -v   dd-to на четене вече дава 3.0 GB/s ???. Другите тестове hdparm и писне на файл си остават същите.

Така и обаче не успаях да разбера трябва ли да се монтира с discard или трябва да се пуска периодично fstrim? Различни мнения чета по нета. Centos 7 при инсталация нищо не е направил по въпроса (даже и noatime не е добавил :o). Обаче има едни налични сървиси в systemd  fstrim.timer и fstrim.service
Тук пише че трябвало да се пуснат https://www.certdepot.net/rhel7-extend-life-ssd/



Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: makeme в Dec 28, 2019, 15:43
Според тази ($2) статия може да си го пускаш като на Ubuntu.
При Ubuntu е просто крон, който пуска fstrim командата. С това казано, бих ти препоръчал този метод.

Относно discard - в същата статия пише, че е нужен само, ако НЕ тримваш.

Това със системд-то не мога да го схвана, но и при мен на Ubuntu, гледам че е пуснато:

Код
GeSHi (Bash):
  1. $ systemctl list-timers
  2. NEXT                         LEFT          LAST                         PASSED       UNIT                         ACTIVATES
  3. Sat 2019-12-28 16:01:15 EET  19min left    Sat 2019-12-28 15:04:14 EET  37min ago    anacron.timer                anacron.service
  4. Sat 2019-12-28 16:40:56 EET  59min left    Sat 2019-12-28 03:16:32 EET  12h ago      apt-daily.timer              apt-daily.service
  5. Sat 2019-12-28 18:36:30 EET  2h 54min left Fri 2019-12-27 12:36:16 EET  1 day 3h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
  6. Sat 2019-12-28 19:50:37 EET  4h 8min left  Sat 2019-12-28 05:00:02 EET  10h ago      motd-news.timer              motd-news.service
  7. Sun 2019-12-29 06:20:12 EET  14h left      Sat 2019-12-28 11:27:12 EET  4h 14min ago apt-daily-upgrade.timer      apt-daily-upgrade.service
  8. ----->  Mon 2019-12-30 00:00:00 EET  1 day 8h left Mon 2019-12-23 00:00:01 EET  5 days ago   fstrim.timer                 fstrim.service
  9. n/a                          n/a           Tue 2019-12-24 05:31:28 EET  4 days ago   ureadahead-stop.timer        ureadahead-stop.service
  10.  

Може би самата команда го е пуснала.


Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: Naka в Dec 29, 2019, 09:19
Това със системд-то не мога да го схвана.

Абе и аз не можаш да го схвана...Нещо много ме мързи да чета по празниците и затова чакам някой да ме светне >:D
Обаче проверих в конфиговете на cron-a. Там няма нищо зададено за fstrim. Да не би системд да играе ролята и на алтернативен 'cron'. ???


Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: makeme в Dec 29, 2019, 12:32
Това със системд-то не мога да го схвана.

Абе и аз не можаш да го схвана...Нещо много ме мързи да чета по празниците и затова чакам някой да ме светне >:D
Обаче проверих в конфиговете на cron-a. Там няма нищо зададено за fstrim. Да не би системд да играе ролята и на алтернативен 'cron'. ???
Да, при centos-а го няма крона, но може да си го направиш. Има го в Ubuntu.
За файловете на системд-то - аз ги нямам в указания път, но може да провериш при теб -> /usr/lib/systemd/system/

ПП: Всъщност те подведох :) . На новото Ubuntu го няма като крон и е като на centos-а (сега взе да ми се изяснява :) ):
https://askubuntu.com/questions/1034169/is-trim-enabled-on-my-ubuntu-18-04-installation
От този линк виж командите за проверка и пускането му.


Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: 4096bits в Dec 29, 2019, 21:55
Добре, моите пет цента към дискусията.
Подарих единия лаптоп на брат ми, като първо му поставих ssd, максимално рам... Та, впросът ми е, достатъчно ли е за машина, която ще се полва за тривиални цели, най-много някоя обработка на видео да се случи два пъти в месеца, .... достатъчно ли е, да поставя discard в fstab?


Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: jet в Dec 29, 2019, 22:10
... Та, впросът ми е, достатъчно ли е за машина, която ще се полва за тривиални цели, най-много някоя обработка на видео да се случи два пъти в месеца, .... достатъчно ли е, да поставя discard в fstab?
Да, достатъчно е и това е предпочитания метод и по-малко се хаби диска.


Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: Naka в Dec 30, 2019, 10:50
... Та, впросът ми е, достатъчно ли е за машина, която ще се полва за тривиални цели, най-много някоя обработка на видео да се случи два пъти в месеца, .... достатъчно ли е, да поставя discard в fstab?
Да, достатъчно е и това е предпочитания метод и по-малко се хаби диска.

В смисъл discard в fstab е много по-добре от периодично пускане на fstrim и по-малко хаби диска?

Обаче съм чувал и противоположни мнения, че разбираш ли постоянно изпращани команди за трим от 'fstab' ;D хабяло диска щото диска трябвало всеки път да ги изпълнява и да търка....... А периодичното с fstrim било по щадящо.
Обаче според мене такова мнение е глупост. Щото трима само съобщава на firmware на диска, че някой сектор е свободен. Ако втори,трети или n-ти път го съобщи какво? firmware-а трябва да е много, ама много глупав, та да повтори пак операцията или да изтърка сектора или пак да го отблежи отново като празен.

Освен това си мисля че цялата информация за това къде и какво свободно място има и кой сектор колко е бил натоварен - т.е цялата информацията за ware leveling се записва не в основния дата епром (не в TLC, QLC флашовете, който имат малък живот 10к). А се записва в отделен стандартен епром, който е от старата епром технология с 1 бит на клетка и има живот 100к-1М записи.
Вероятно в него се намира и този буфер 40GB, който е най-натоварения.


Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: Dojnow в Dec 31, 2019, 10:57
 От
Код:
man fstrim
"Running fstrim frequently, or even using mount -o discard, might negatively affect the lifetime of poor-quality SSD devices. For most desktop and server systems the sufficient trimming frequency is once a week. Note that not all devices support a queued trim, so each trim command incurs a performance penalty on whatever else might be trying to use the disk at the time."
 и Solid state drive/Continuous TRIM https://wiki.archlinux.org/index.php/Solid_state_drive#Continuous_TRIM ($2) :
 "Note: Continuous TRIM is not the most preferred way to issue TRIM commands among the Linux community. For example, Ubuntu enables periodic TRIM by default [5], Debian does not recommend using continuous TRIM [6] and Red Hat recommends using periodic TRIM over using continuous TRIM if feasible. [7]", както и предупреждението по-горе.
 и SSDOptimization/Mounting SSD filesystems https://wiki.debian.org/SSDOptimization#Mounting_SSD_filesystems ($2) :
 "The "discard" options is not needed if your SSD has enough overprovisioning (spare space) or you leave (unpartitioned) free space on the SSD."
 Обяснението е дадено в Plextor M5M (256GB) mSATA Review https://www.anandtech.com/print/6722/plextor-m5m-256gb-msata-review ($2) в параграфите съдържащи "garbage collection" и "over-provisioning".
 Така че просто (дори с Continuous TRIM) трябва да се оставя достатъчно неизползвано пространство на диска, което е валидно и за HDD, но там е за минимизиране на фрагментирането.


Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: go_fire в Dec 31, 2019, 11:30
Добре де, за какво фрагментиране става въпрос? Аз ли недоразбирам или темата е за SSD?


Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: 4096bits в Dec 31, 2019, 11:56
Фрагментирането дори се прави нарочно при ssd-тата. Всяко парче памет да получава равномерно количество записи. А не едни да се натоварват повече, други изобщо. Но дори да оставим това настрани, какво значение има фрагментирането, при положение, че имаш директен достъп? Не чакаш, да се позиционират глави за четене/запис.


Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: go_fire в Dec 31, 2019, 12:10
Това имах предвид.


Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: Dojnow в Dec 31, 2019, 14:00
Добре де, за какво фрагментиране става въпрос? Аз ли недоразбирам или темата е за SSD?
Първият параграф в Performance Consistency https://www.anandtech.com/show/6722/plextor-m5m-256gb-msata-review/3 ($2) Всяка памет, вкл. SSD и RAM, в която се записват, изменят и изтриват (структури от) данни се фрагментира. Един файл може да се помести в един или повече последователни 512 KB, 1 MB, 2 MB, ... блокове, а може да е разпръснат и в непоследователни, което не е добре за скоростта на запис и износването, както трябва да се има предвид и "Partitions Alignment".


Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: Naka в Dec 31, 2019, 15:18
На мен не ми харесва думата фрагментиране. Това си е нещо вътрешно за SSD до което нямаш достъп. Как си ги разоределя и менка вътрешно блоковете (с цел разпределяне на износването)  се е негова вътрешна работа. Отвънка обаче LBA секторите изглеждат последователно.


Подравняването на партициите обаче е много важно нещо. Според онази статия на Сеагете вътрешно дисковете имат 4096 битови сектори, обаче външно ги съобщават на 512. Т. Е цепят сектора на 8 части.
Затова партицията трябва да почва на число делящо се на 4096 байта на цяло число без остатък (ако гледаме началната стойност на дяла в байтове.)

Ако гледаме началната стойнист на дяла в LBA секори трябва числото да се дели без остатък на 8.

Ако това условие Не е изпълнено например  когато   се чете 1 сектор (512байта)  вместо да се прочете 1сектор винаги ще се четят два съседни сектора. Защото сектора ще се разпредели върху два съседне 4096 вътрешни физически сектора. Съжалявам че не мога да дам пример сега щото мажа на таб. Но го проверих. Сентос 7 инсталацията се съобразява с това и наисина прави дялове които да почват кратно на 4096 байта. Gparted също се съобразява и ги подравнява.

https://www.seagate.com/gb/en/tech-insights/advanced-format-4k-sector-hard-drives-master-ti/

---
Сега да не вземе някой да каже че това било само за хардовете. Вътрешно ssd работят и търкат даже по големи блокове от фалш памет от 4096. Но понеже няма друга информащия по въпроса а и цялата индустрия явно се е насочилила към 4096 блокове то ще се съобразяваме с кратно на 4096 байта.

Прочетох също че единствено intel SSD имали в програмата им за управление опция за смяна на сектора на 4096. Така че и външно да го съобщава на 4096. Но тази смяна било по съществото си флашване на нов firmware. А моят кингстън е 512 секторен, както и всички продавани ssd-та.






Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD
Публикувано от: Naka в Jan 04, 2020, 11:50
Ето как е направил инсталацията Центос7 и е подравнил дяловете.
на ССД-то 500GB (nvme0n1) има два дяла.
boot 1GB и root / останалото.

[root@sabi ~]# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0 465.8G  0 disk
├─sda1        8:1    0  15.6G  0 part [SWAP]
└─sda2        8:2    0 450.1G  0 part /home
sdb           8:16   0 465.8G  0 disk
└─sdb1        8:17   0 465.8G  0 part
sr0          11:0    1  1024M  0 rom 
nvme0n1     259:0    0 465.8G  0 disk
├─nvme0n1p1 259:1    0     1G  0 part /boot
└─nvme0n1p2 259:2    0 464.8G  0 part /
[root@sabi ~]#
[root@sabi ~]#
[root@sabi ~]# fdisk /dev/nvme0n1
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p

Disk /dev/nvme0n1: 500.1 GB, 500107862016 bytes, 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x8ce42bb8

        Device Boot      Start         End      Blocks   Id  System
/dev/nvme0n1p1   *        2048     2099199     1048576   83  Linux
/dev/nvme0n1p2         2099200   976773119   487336960   83  Linux

Command (m for help): q


fdisk-a ги изобразява началото и края на дяловете в LBA Сектори по 512 байта.
(накрая обаче има една колона Blocks за големината на дяла и е в размерност x 1024 - защо така го изобразява не е ясно и тази колона не бива да се гледа)

boot -дяла започва на (2048 x 512) /4096 = 256 (цяло число)
/      -дяла започва на (2099200 x 512) /4096 = 262400 (цяло число)

ако например /      -дяла започваше на друг сектор например 2099201
(2099201 x 512) /4096 = 262400.125 (дробно число) което ще е грешно и най вероятно системата ще работи по бавно и диска ще се износва повече.