Изпечатай

[jet]

При мен:
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 за съжаление

[Naka]

SSD
   User Capacity:    480,103,981,056 bytes [480 GB], 937703088 sectors

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

[go_fire]

   Малко встрани от темата,тъй като имам малък опит със SSD дискове,
искам да попитам за какъв обем дисково пространство става дума ?
   GB или GiB ?
   Съгласно някакви нови стандарти 1 GB е 1000*1000*1000 байта,
а 1 GiB е 1024*1024*1024 байта.
   Горе се говореше за 500GB, въпроса е : 500GB или 500GiB ?
При класическите твърди дискове понякога производителите послъгват...
Маркетингови трикове ...

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

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

[remotexx]

Кратка историческа справка - истината е, че простолюдието си държи на своето, независимо колко е тъпо и колко противоречи на науката (аз затова препочитам ИИ)

1. Всеки ел. техник ше ви каже че тия означения - pico, nano, micro и нагоре kilo mega и пр. по стандарт (вкл. и международен) се изписват с малка буква - kV, mW, pF и т.н. те затова навремето по дисковете минаха на главни букви където вече К = 2¹⁰ = 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 = 10³ пък и 1024 ( 8 ) = 1*8³ + 2*8 + 4 = 512 + 16 +4 = 532 (10) което не е близо до нищо кръгло (десетично) ...совен може бо до половинката на 1000 ама не е кръгло число, а и повечето хора не могат да смятат hex 

[jet]

Абе важното е, че така производителите икономисват една плоча в HDD или един чип в SSD (при милиони бройки, това си е бонуса на CEO-то).
Сега такива дебати се водят и как да се мери пробега на EV-тата.

[Naka]

Взех Кинстана А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, http://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 не е добавил ). Обаче има едни налични сървиси в systemd  fstrim.timer и fstrim.service
Тук пише че трябвало да се пуснат https://www.certdepot.net/rhel7-extend-life-ssd/

[makeme]

Според тази статия може да си го пускаш като на Ubuntu.
При Ubuntu е просто крон, който пуска fstrim командата. С това казано, бих ти препоръчал този метод.

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

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

Код

GeSHi (Bash):
$ systemctl list-timers
NEXT                         LEFT          LAST                         PASSED       UNIT                         ACTIVATES
Sat 2019-12-28 16:01:15 EET  19min left    Sat 2019-12-28 15:04:14 EET  37min ago    anacron.timer                anacron.service
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
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
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
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
----->  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
n/a                          n/a           Tue 2019-12-24 05:31:28 EET  4 days ago   ureadahead-stop.timer        ureadahead-stop.service
 

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

[Naka]

Това със системд-то не мога да го схвана.

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

[makeme]

Това със системд-то не мога да го схвана.

Абе и аз не можаш да го схвана...Нещо много ме мързи да чета по празниците и затова чакам някой да ме светне
Обаче проверих в конфиговете на 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
От този линк виж командите за проверка и пускането му.

[4096bits]

Добре, моите пет цента към дискусията.
Подарих единия лаптоп на брат ми, като първо му поставих ssd, максимално рам... Та, впросът ми е, достатъчно ли е за машина, която ще се полва за тривиални цели, най-много някоя обработка на видео да се случи два пъти в месеца, .... достатъчно ли е, да поставя discard в fstab?

[jet]

... Та, впросът ми е, достатъчно ли е за машина, която ще се полва за тривиални цели, най-много някоя обработка на видео да се случи два пъти в месеца, .... достатъчно ли е, да поставя discard в fstab?

Да, достатъчно е и това е предпочитания метод и по-малко се хаби диска.

[Naka]

... Та, впросът ми е, достатъчно ли е за машина, която ще се полва за тривиални цели, най-много някоя обработка на видео да се случи два пъти в месеца, .... достатъчно ли е, да поставя discard в fstab?

Да, достатъчно е и това е предпочитания метод и по-малко се хаби диска.

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

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

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

[Dojnow]

 От

Код:

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 :
 "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 :
 "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 в параграфите съдържащи "garbage collection" и "over-provisioning".
 Така че просто (дори с Continuous TRIM) трябва да се оставя достатъчно неизползвано пространство на диска, което е валидно и за HDD, но там е за минимизиране на фрагментирането.

[go_fire]

Добре де, за какво фрагментиране става въпрос? Аз ли недоразбирам или темата е за SSD?

[4096bits]

Фрагментирането дори се прави нарочно при ssd-тата. Всяко парче памет да получава равномерно количество записи. А не едни да се натоварват повече, други изобщо. Но дори да оставим това настрани, какво значение има фрагментирането, при положение, че имаш директен достъп? Не чакаш, да се позиционират глави за четене/запис.