Титла: Бавен трансфер от стар 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 Предположението ми за 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 ПП: Имай предвид че с 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За 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 * Колко пълен е този диск/партишън. Когато е много пълен диска се забавя. Чак пък толкова от един непуснат трим да падне от 540мб/сек на 80 мб/сек :o :o :o Но е възможно изобщо да не бил пуснат (win7) защото биоса беше на IDE а не на AHCI. Колегата тука разправя че за trim под виндовс трябвало AHCI ??? Диска е пълен на половина. По скоро ми мяза на много стар модел/версия или бъгъв firmware. Както и да е диска вече е при клиента и не мога да експериментирам. А и беше пълен с важна информация. Титла: Re: Бавен трансфер на SSD Публикувано от: Naka в Dec 13, 2019, 13:39 А какво мислите за този диск? Друг варянт който ми се вижда хубав е 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 Което прави 512 байтови сектори. Титла: Re: Бавен трансфер от стар SSD и избор на М.2 SSD Публикувано от: go_fire в Dec 15, 2019, 13:01 Малко встрани от темата,тъй като имам малък опит със SSD дискове, А бе не знам, какво пишат и не пишат производителите, но 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, гледам че е пуснато: Код
Може би самата команда го е пуснала. Титла: 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 Да, при 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 и 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 (дробно число) което ще е грешно и най вероятно системата ще работи по бавно и диска ще се износва повече. |