[megahertz0]

Привет!

Есть один сервер на Debain 7 (ядро 3.2.0-4). На нем крутится БД mysql, лежащая на SSD (Intel DC S3700). Требуется заменить SSD  по причине нехватки емкости и большой наработки (почти 3 года). И тут возник вопрос. Если собрать из двух SSD (DC S3610) зеркало на md, то как будут обстоять дела с TRIM? Если мне не изменяет память, то через md вообще не передается TRIM на диски (возможно я ошибаюсь). В общем, есть ли у кого-то опыт эксплуатации SSD (не важно, Intel или нет) в md RAID и как они себя там ведут? И как себя ведут диски при отключенном или не передающемся TRIM?

[rm_]

55 minutes ago, megahertz0 said:

через md вообще не передается TRIM на диски

Передаётся. Не скажу правда за 3.2 ядро, но в нынешних передаётся точно.

[anix]

1 час назад, megahertz0 сказал:

Требуется заменить SSD  по причине нехватки емкости и большой наработки (почти 3 года).

У SSD есть ключевой показатель Media Wearout Indicator, показывающий остаточный ресурс записи в %, посмотреть можно с помощью smartctl -a /dev/sda | grep Wearout.
Ресурс записи измеряют в TBW и отражают в документации.
Для Intel S3700 (хорошая серия) в доке пишут про:

Endurance: 10 drive writes per day for 5 years

https://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/ssd-dc-s3700-spec.pdf

[st_re]

37 минут назад, anix сказал:

У SSD есть ключевой показатель Media Wearout Indicator, показывающий остаточный ресурс записи в %, посмотреть можно с помощью smartctl -a /dev/sda | grep Wearout.
 

Это ОЧЕНЬ зависит от модели SSD... Каждый производитель тут себе сам придумывает чтото..  У меня вот нет Wearout, но есть 

smartctl -l ssd /dev/sdc
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.15.17-200.fc26.x86_64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

Device Statistics (GP Log 0x04)
Page  Offset Size        Value Flags Description
0x07  =====  =               =  ===  == Solid State Device Statistics (rev 1) ==
0x07  0x008  1               0  N--  Percentage Used Endurance Indicator

Это 0%, но у меня есть SSD со 170% использования и ничего, работает себе.. смерть на подобной наступила на 220% гдето..

 

Есть гдето в запасе SSD и без того и без другого..Но там были какието косвенные параметры, сейчас такие не стоят нигде у меня, чтобы быстро глянуть..

 

[megahertz0]

Ну, на счет ресурса согласен.  DC S3700 вообще очень живучие SSD. У меня на одном из них лежит БД Заббикса, где-то 70 ГБ.  За 3 года записано почти 500 ТБ данных и работает он в основном на запись:

Скрытый текст

megahertz@zabbix:~$ sudo smartctl -a /dev/sdc
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-3.2.0-4-amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Intel 730 and DC S35x0/3610/3700 Series SSDs
Device Model:     INTEL SSDSC2BA100G3
Serial Number:    BTTV33540A1W100FGN
LU WWN Device Id: 5 5cd2e4 04b47c73f
Firmware Version: 5DV10265
User Capacity:    100 030 242 816 bytes [100 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 2.6, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Wed May 16 19:51:35 2018 MSK
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

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

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
Total time to complete Offline
data collection:                (    0) seconds.
Offline data collection
capabilities:                    (0x79) SMART execute Offline immediate.
                                        No Auto Offline data collection support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine
recommended polling time:        (   1) minutes.
Extended self-test routine
recommended polling time:        (   2) minutes.
Conveyance self-test routine
recommended polling time:        (   2) minutes.
SCT capabilities:              (0x003d) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0032   100   100   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       36280
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       43
170 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  Always       -       0
171 Program_Fail_Count      0x0032   100   100   000    Old_age   Always       -       0
172 Erase_Fail_Count        0x0032   100   100   000    Old_age   Always       -       0
174 Unsafe_Shutdown_Count   0x0032   100   100   000    Old_age   Always       -       37
175 Power_Loss_Cap_Test     0x0033   100   100   010    Pre-fail  Always       -       651 (215 2368)
183 SATA_Downshift_Count    0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0033   100   100   090    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
190 Temperature_Case        0x0022   081   073   000    Old_age   Always       -       19 (Min/Max 14/39)
192 Unsafe_Shutdown_Count   0x0032   100   100   000    Old_age   Always       -       37
194 Temperature_Internal    0x0022   100   100   000    Old_age   Always       -       19
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       0
199 CRC_Error_Count         0x003e   100   100   000    Old_age   Always       -       0
225 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       15102791
226 Workld_Media_Wear_Indic 0x0032   100   100   000    Old_age   Always       -       12237
227 Workld_Host_Reads_Perc  0x0032   100   100   000    Old_age   Always       -       18
228 Workload_Minutes        0x0032   100   100   000    Old_age   Always       -       1907456
232 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  Always       -       0
233 Media_Wearout_Indicator 0x0032   087   087   000    Old_age   Always       -       0
234 Thermal_Throttle        0x0032   100   100   000    Old_age   Always       -       0/0
241 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       15102791
242 Host_Reads_32MiB        0x0032   100   100   000    Old_age   Always       -       2963408

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

 

Тут вопрос в том как передается TRIM через md если md по сути фиолетово что за ФС на нем, а TRIM выполняется на основе данных ФС о свободных блоках. И самое главное. Что будет если диск активно напрягать на запись (как на примере), но при этом не делать TRIM вообще.

[st_re]

ну на центоси от 7.2 (откуда начиная вопрос у нас был актуален, скорее всего и раньше) через MD трим проходит.. не без приколов.. рейд 0 и 1 (и соотвественно 10) нормально, а вот 5, (ну и 3 и 6, т.к. там один обработчик) нужно 1 поставить в sysctl, но дальше, они впендюрили белый список поддерживаемых устройств, которые возвращают нужные значения (не помню, нули кажется) после трима, типа бывают устройства, которые возвращают чтото другое и это им ломало логику.. вместо черного списка там белый, ну и как назло наши SSD возвращали, если проверить, потримить и почитать потом сектора, то, что надо, но в списке их небыло. и хрен. (понятно что можно было бы пересобрать модуль, дописав нужные названия в список, но решили другим методом, список, как это не странно, не в модуле рейда, а в модуле контроллера, смена контроллера волшебным образом проблему решила с теми же самыми SSD и тем же самым рейдом.

 

И цифры по скорости записи, чтобы там не трендели производители серверных железок, говорят за то, что трим делать надо.

 

 

[EugeneP]

Это зависит от ФС которая поверх mdadm. Чтобы включить trim для ext4, нужно добавить опцию discard в опции монтирования.

В десятке серверов стоят DC3500, года три как без сбоев.

[rm_]

1 hour ago, EugeneP said:

Это зависит от ФС которая поверх mdadm.

Вопрос у автора поддерживает ли mdadm пропуск TRIM в принципе.

 

1 hour ago, EugeneP said:

Чтобы включить trim для ext4, нужно добавить опцию discard в опции монтирования.

Это чтобы включить автоматический TRIM выполняемый самой ФС. Но это не рекомендуется делать, в том числе и разработчиками самой ФС тоже -- с точки зрения надёжности (у ряда SSD имеются разные мутные глюки с отработкой TRIM) и производительности (зачастую это не-queued операция, т.е. на всё её время обрабатываемые IOPS падают до нуля). Текущая рекомендация - опцию discard не использовать, вместо этого в crontab поставить запуск программы fstrim для этой ФС на ~раз в сутки, в период наименьшей нагрузки. 

[st_re]

Но если ССД большая и свободного места много, то fstrim ставить раком будет довольно на долго систему..  если система активно используется 24*7 то.. в общем местами мы включили TRIM на монтировании. Тогда оно тримит только то, что стерло, а не весь тер скопом. в нашем случае это оказалось меньшим злом. Но да, лучше бы таки fstrim переодический, но не всегда приемлемо..

[Tosha]

Нормальные серверные SSD диски имеют размер меньше "круглого", например, 200 а не 256 и вот на таких вообще можно не заботиться о Trim - там всегда есть пул чистых страниц для быстрой записи. Ну раз в год можно дать команду fstrim

[st_re]

Наши тесты говорят, что для всех нашиих надо... скорость записи просаживается через некоторе время, если трим не делать. Когда сделаешь, снова ровно. :) тестировать надо, а рекламные проспекты даже не смотреть в жтом вопросе, там они все супер.

 

А раз в год или раз в неделю это от объема записи записи зависит.. у меня есть одна машинка где за год с небольшой мелочью в те 220% (smartctl -l ssd) утерлась ССД 200Г размером, где ниразу больше 10Г одновременно занято и небыло.. но и трима ниразу небыло, т.к рейд контроллер и он ни в JBOD ни как еще трим не пропускает.  теперь там 500, но даже посмотреть то нельзя сколько натерло....

500Г ССД под базой от забикса утерлась в 100% через год и пару месяцев, потом резко снизили объемы записи  и вот уже прошло еще полтора года и теперь там 170%.. как бы от забикса принято решение отказываться. помрет, вот и откажемся :) Но пока работает.

[rm_]

2 hours ago, st_re said:

Но если ССД большая и свободного места много, то fstrim ставить раком будет довольно на долго систему

Зависит ещё от ФС. Ext4 например запоминает уже тримнутые области (discard'ом или fstrim), и при повторных вызовах fstrim их больше не тримает. A Btrfs не запоминает. Не знаю насчёт XFS/JFS.

[st_re]

xfs, судя по времени трима, тримает все свободное всегда..

[rm_]

12 hours ago, st_re said:

судя по времени

Можно смотреть fstrim -v, на Ext4 при повторных вызовах сразу же после первого (и без записи на ФС) она возвращает "0 байт trimmed". А на других ФС всегда полное кол-во свободного места (и дольше, конечно).

[st_re]

Там столько по времени на большой почти пустой ссд, чт даже сомнений не вызывало...

 

ну да, вот  прямо сейчас 2 раза подрял. xfs

$ sudo fstrim -v -a
/home: 286,6 GiB (307678965760 bytes) trimmed
$ sudo fstrim -v -a
/home: 286,6 GiB (307677859840 bytes) trimmed
 

[megahertz0]

Собрал в общем схему с md поверх SSD. В итоге fstrim через md до диска не доходит:

root@hs1:/home/megahertz# mount /dev/md2p1 /mnt/s3600/
root@hs1:/home/megahertz# fstrim -v /mnt/s3600/
fstrim: /mnt/s3600/: FITRIM ioctl failed: Неподдерживаемая операция

По крайней мере на Debian 7 и ядре 3.2.68-1.

А еще попробовал погонять fio на голом диске и на диске за md (raid 1) с целью изучить падение производительности на md. Сразу оговорюсь, что SSD подключен через SATA-II, поэтому bandwidth ограничен 3 Gbps.

 

Голый диск:

Скрытый текст

root@hs1:/home/megahertz/fio# fio config.ini
readtest: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=16
writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=16
2.0.8
Starting 2 processes
^Cbs: 2 (f=2): [rw] [5.1% done] [171.4M/154.7M /s] [43.9K/39.6K iops] [eta 47m:38s]
fio: terminating on signal 2

readtest: (groupid=0, jobs=1): err= 0: pid=31388
  read : io=26028MB, bw=174666KB/s, iops=43666 , runt=152595msec
    slat (usec): min=1 , max=321 , avg= 3.35, stdev= 1.60
    clat (usec): min=32 , max=300184 , avg=362.14, stdev=1564.84
     lat (usec): min=35 , max=300197 , avg=365.61, stdev=1564.86
    clat percentiles (usec):
     |  1.00th=[  104],  5.00th=[  161], 10.00th=[  191], 20.00th=[  227],
     | 30.00th=[  258], 40.00th=[  290], 50.00th=[  318], 60.00th=[  346],
     | 70.00th=[  374], 80.00th=[  410], 90.00th=[  466], 95.00th=[  548],
     | 99.00th=[ 1160], 99.50th=[ 2024], 99.90th=[ 3536], 99.95th=[ 3856],
     | 99.99th=[99840]
    bw (KB/s)  : min=66404, max=248888, per=100.00%, avg=175082.83, stdev=13247.14
    lat (usec) : 50=0.02%, 100=0.81%, 250=26.35%, 500=65.72%, 750=5.23%
    lat (usec) : 1000=0.68%
    lat (msec) : 2=0.68%, 4=0.47%, 10=0.02%, 50=0.01%, 100=0.01%
    lat (msec) : 250=0.02%, 500=0.01%
  cpu          : usr=8.02%, sys=25.55%, ctx=5839144, majf=0, minf=38
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=6663284/w=0/d=0, short=r=0/w=0/d=0
writetest: (groupid=0, jobs=1): err= 0: pid=31389
  write: io=23215MB, bw=155794KB/s, iops=38948 , runt=152584msec
    slat (usec): min=1 , max=365 , avg= 3.63, stdev= 1.68
    clat (usec): min=47 , max=297194 , avg=406.22, stdev=1434.24
     lat (usec): min=51 , max=297197 , avg=409.97, stdev=1434.24
    clat percentiles (usec):
     |  1.00th=[  114],  5.00th=[  199], 10.00th=[  251], 20.00th=[  310],
     | 30.00th=[  342], 40.00th=[  362], 50.00th=[  386], 60.00th=[  414],
     | 70.00th=[  446], 80.00th=[  482], 90.00th=[  524], 95.00th=[  556],
     | 99.00th=[  604], 99.50th=[  628], 99.90th=[  684], 99.95th=[  716],
     | 99.99th=[99840]
    bw (KB/s)  : min=113448, max=221672, per=100.00%, avg=155943.88, stdev=8628.31
    lat (usec) : 50=0.01%, 100=0.45%, 250=9.52%, 500=74.91%, 750=15.08%
    lat (usec) : 1000=0.01%
    lat (msec) : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.01%, 50=0.01%
    lat (msec) : 100=0.01%, 250=0.02%, 500=0.01%
  cpu          : usr=8.48%, sys=24.14%, ctx=5808761, majf=0, minf=23
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=5942912/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=26028MB, aggrb=174665KB/s, minb=174665KB/s, maxb=174665KB/s, mint=152595msec, maxt=152595msec
  WRITE: io=23215MB, aggrb=155793KB/s, minb=155793KB/s, maxb=155793KB/s, mint=152584msec, maxt=152584msec

Disk stats (read/write):
  sdh: ios=6657262/5937504, merge=0/0, ticks=2398256/2397736, in_queue=4796996, util=100.00%

 

И за md:

Скрытый текст

root@hs1:/home/megahertz/fio# fio config.ini
readtest: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=16
writetest: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=16
2.0.8
Starting 2 processes
^Cbs: 2 (f=2): [rw] [5.2% done] [209.1M/89564K /s] [53.8K/22.4K iops] [eta 57m:15s]
fio: terminating on signal 2

readtest: (groupid=0, jobs=1): err= 0: pid=25571
  read : io=32171MB, bw=175172KB/s, iops=43792 , runt=188064msec
    slat (usec): min=1 , max=441 , avg= 2.85, stdev= 1.22
    clat (usec): min=29 , max=300177 , avg=361.64, stdev=3926.21
     lat (usec): min=32 , max=300183 , avg=364.59, stdev=3926.23
    clat percentiles (usec):
     |  1.00th=[   65],  5.00th=[   91], 10.00th=[  104], 20.00th=[  131],
     | 30.00th=[  155], 40.00th=[  177], 50.00th=[  199], 60.00th=[  223],
     | 70.00th=[  247], 80.00th=[  278], 90.00th=[  330], 95.00th=[  374],
     | 99.00th=[  474], 99.50th=[  564], 99.90th=[99840], 99.95th=[99840],
     | 99.99th=[100864]
    bw (KB/s)  : min=41412, max=287160, per=100.00%, avg=176469.72, stdev=41962.15
    lat (usec) : 50=0.18%, 100=7.97%, 250=63.11%, 500=27.99%, 750=0.45%
    lat (usec) : 1000=0.05%
    lat (msec) : 2=0.04%, 4=0.03%, 10=0.01%, 20=0.01%, 50=0.02%
    lat (msec) : 100=0.03%, 250=0.11%, 500=0.01%
  cpu          : usr=6.80%, sys=26.85%, ctx=7263969, majf=0, minf=39
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=8235871/w=0/d=0, short=r=0/w=0/d=0
writetest: (groupid=0, jobs=1): err= 0: pid=25572
  write: io=23751MB, bw=129325KB/s, iops=32331 , runt=188058msec
    slat (usec): min=1 , max=474 , avg= 2.40, stdev= 0.86
    clat (usec): min=23 , max=300389 , avg=491.61, stdev=5854.64
     lat (usec): min=49 , max=300393 , avg=494.11, stdev=5854.65
    clat percentiles (usec):
     |  1.00th=[   77],  5.00th=[  101], 10.00th=[  122], 20.00th=[  151],
     | 30.00th=[  177], 40.00th=[  203], 50.00th=[  227], 60.00th=[  253],
     | 70.00th=[  282], 80.00th=[  318], 90.00th=[  374], 95.00th=[  434],
     | 99.00th=[  548], 99.50th=[  580], 99.90th=[99840], 99.95th=[100864],
     | 99.99th=[199680]
    bw (KB/s)  : min=30885, max=242208, per=100.00%, avg=130981.28, stdev=35490.97
    lat (usec) : 50=0.01%, 100=3.74%, 250=55.28%, 500=38.85%, 750=1.88%
    lat (usec) : 1000=0.01%
    lat (msec) : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.01%, 50=0.01%
    lat (msec) : 100=0.02%, 250=0.18%, 500=0.01%
  cpu          : usr=6.51%, sys=18.09%, ctx=5826033, majf=0, minf=24
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=6080150/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=32171MB, aggrb=175171KB/s, minb=175171KB/s, maxb=175171KB/s, mint=188064msec, maxt=188064msec
  WRITE: io=23751MB, aggrb=129324KB/s, minb=129324KB/s, maxb=129324KB/s, mint=188058msec, maxt=188058msec

Disk stats (read/write):
    md2: ios=8231265/6079150, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=8236023/6080151, aggrmerge=1066/0, aggrticks=2951188/2951720, aggrin_queue=5910712, aggrutil=100.00%
  sdh: ios=8236023/6080151, merge=1066/0, ticks=2951188/2951720, in_queue=5910712, util=100.00%

 

Итого получается, что при чтении md не особенно влияет на bandwidth, но все таки  несколько ухудшает ее. Но, похоже, в пределах погрешности. Latency в среднем не меняется, но стандартное отклонение заметно выше на md.

На запись все примерно так же.

[rm_]

19 minutes ago, megahertz0 said:

По крайней мере на Debian 7 и ядре 3.2.68-1.

Таки да, это добавили с ядра 3.7: https://kernelnewbies.org/Linux_3.7#Block

[st_re]

1 час назад, megahertz0 сказал:

обрал в общем схему с md поверх SSD. В итоге fstrim через md до диска не доходит:

root@hs1:/home/megahertz# mount /dev/md2p1 /mnt/s3600/
root@hs1:/home/megahertz# fstrim -v /mnt/s3600/
fstrim: /mnt/s3600/: FITRIM ioctl failed: Неподдерживаемая операция

 

echo "options raid10 devices_discard_performance=Y" > /etc/modprobe.d/md-raid10.conf    # для RAID0 и RAID1
echo "options raid456 devices_handle_discard_safely=Y" > /etc/modprobe.d/raid456.conf # для RAID 4, 5 или 6

???

(применяется при загрузке)

[edo]

В 5/18/2018 в 21:38, st_re сказал:

Наши тесты говорят, что для всех нашиих надо... скорость записи просаживается через некоторе время, если трим не делать. Когда сделаешь, снова ровно. :)

речь именно про серверные диски?

[st_re]

Ну у производителя заявлялось, что серверное... но, честно, сэкономили и ничего сильно дорогого не брали, больно на требуемых объемах из бюджета вываливались. Скорее всего бывает лучше.  Я же там написал, "для наших" :)

 

В общем  я имел в виду, что перед запуском в продакшн тестировать надо на вашй нагрузке ваши ССД, а не проспекты читать. Если тесты покажут, что трим не нужен, то слава кпсс... А вот если производитель наобещает горы золотые, то их, внезапно, может не оказаться там... Сюрприз будет.

 

[rm_]

6 hours ago, st_re said:

Если тесты покажут, что трим не нужен, то слава кпсс...

Нужен, хотя бы с т.з. долговечности. Да и вообще если нет непреодолимых препятствий его использовать, эксплуатировать без него - всё равно что ездить на автомобиле у которого что-то стучит в двигателе.

А в данном случае таких препятствий нет, для Debian 7 штатно доступно более новое ядро 3.16:

https://packages.debian.org/wheezy-backports/linux-image-3.16.0-0.bpo.4-amd64

[snvoronkov]

1 час назад, rm_ сказал:

А в данном случае таких препятствий нет, для Debian 7 штатно доступно более новое ядро 3.16:

Backports - это не совсем штатно. Даже, наверное, совсем не штатно.

[rm_]

38 minutes ago, snvoronkov said:

Backports - это не совсем штатно. Даже, наверное, совсем не штатно.

Штатно enough :), на порядок штатнее чем собирать самому.

[megahertz0]

Вот какой итог получается. Обновил систему на Debian 8, ядро 3.16.56-1+deb8u1. SSD собрал в зеркало. Разметил на массиве раздел, отформатировал его в ext4 без какой-то особой магии и смонтировал.

 

fstrim вроде выполнился:

root@hs1:/home/megahertz# fstrim -v /var/lib/mysql
/var/lib/mysql: 368,7 GiB (395904679936 bytes) trimmed

Похоже и правда начиная с Debian 8 md научился пропускать fstrim до дисков.

[st_re]

2 часа назад, megahertz0 сказал:

Похоже и правда

blktrace -d /dev/sda -a discard -o - | blkparse -i -

посмотрите, долетает ли до sda..

 

ну или записать кучу заранее известного мусора,найти её физически на sdX чтобы она DD отдавалась, стереть файл, сказать трим, сбросить кеши (echo 1 > /proc/sys/vm/drop_caches) и почитать оттуда же.. на большинстве SSD приедут нули, если трим сработал.. или тоже самое что было записано, если не сработал..