megahertz0 Posted May 16, 2018 Posted May 16, 2018 Привет! Есть один сервер на 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? Вставить ник Quote
rm_ Posted May 16, 2018 Posted May 16, 2018 55 minutes ago, megahertz0 said: через md вообще не передается TRIM на диски Передаётся. Не скажу правда за 3.2 ядро, но в нынешних передаётся точно. Вставить ник Quote
anix Posted May 16, 2018 Posted May 16, 2018 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 Вставить ник Quote
st_re Posted May 16, 2018 Posted May 16, 2018 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 и без того и без другого..Но там были какието косвенные параметры, сейчас такие не стоят нигде у меня, чтобы быстро глянуть.. Вставить ник Quote
megahertz0 Posted May 16, 2018 Author Posted May 16, 2018 Ну, на счет ресурса согласен. 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 вообще. Вставить ник Quote
st_re Posted May 16, 2018 Posted May 16, 2018 ну на центоси от 7.2 (откуда начиная вопрос у нас был актуален, скорее всего и раньше) через MD трим проходит.. не без приколов.. рейд 0 и 1 (и соотвественно 10) нормально, а вот 5, (ну и 3 и 6, т.к. там один обработчик) нужно 1 поставить в sysctl, но дальше, они впендюрили белый список поддерживаемых устройств, которые возвращают нужные значения (не помню, нули кажется) после трима, типа бывают устройства, которые возвращают чтото другое и это им ломало логику.. вместо черного списка там белый, ну и как назло наши SSD возвращали, если проверить, потримить и почитать потом сектора, то, что надо, но в списке их небыло. и хрен. (понятно что можно было бы пересобрать модуль, дописав нужные названия в список, но решили другим методом, список, как это не странно, не в модуле рейда, а в модуле контроллера, смена контроллера волшебным образом проблему решила с теми же самыми SSD и тем же самым рейдом. И цифры по скорости записи, чтобы там не трендели производители серверных железок, говорят за то, что трим делать надо. Вставить ник Quote
EugeneP Posted May 18, 2018 Posted May 18, 2018 Это зависит от ФС которая поверх mdadm. Чтобы включить trim для ext4, нужно добавить опцию discard в опции монтирования. В десятке серверов стоят DC3500, года три как без сбоев. Вставить ник Quote
rm_ Posted May 18, 2018 Posted May 18, 2018 1 hour ago, EugeneP said: Это зависит от ФС которая поверх mdadm. Вопрос у автора поддерживает ли mdadm пропуск TRIM в принципе. 1 hour ago, EugeneP said: Чтобы включить trim для ext4, нужно добавить опцию discard в опции монтирования. Это чтобы включить автоматический TRIM выполняемый самой ФС. Но это не рекомендуется делать, в том числе и разработчиками самой ФС тоже -- с точки зрения надёжности (у ряда SSD имеются разные мутные глюки с отработкой TRIM) и производительности (зачастую это не-queued операция, т.е. на всё её время обрабатываемые IOPS падают до нуля). Текущая рекомендация - опцию discard не использовать, вместо этого в crontab поставить запуск программы fstrim для этой ФС на ~раз в сутки, в период наименьшей нагрузки. Вставить ник Quote
st_re Posted May 18, 2018 Posted May 18, 2018 Но если ССД большая и свободного места много, то fstrim ставить раком будет довольно на долго систему.. если система активно используется 24*7 то.. в общем местами мы включили TRIM на монтировании. Тогда оно тримит только то, что стерло, а не весь тер скопом. в нашем случае это оказалось меньшим злом. Но да, лучше бы таки fstrim переодический, но не всегда приемлемо.. Вставить ник Quote
Tosha Posted May 18, 2018 Posted May 18, 2018 Нормальные серверные SSD диски имеют размер меньше "круглого", например, 200 а не 256 и вот на таких вообще можно не заботиться о Trim - там всегда есть пул чистых страниц для быстрой записи. Ну раз в год можно дать команду fstrim Вставить ник Quote
st_re Posted May 18, 2018 Posted May 18, 2018 Наши тесты говорят, что для всех нашиих надо... скорость записи просаживается через некоторе время, если трим не делать. Когда сделаешь, снова ровно. :) тестировать надо, а рекламные проспекты даже не смотреть в жтом вопросе, там они все супер. А раз в год или раз в неделю это от объема записи записи зависит.. у меня есть одна машинка где за год с небольшой мелочью в те 220% (smartctl -l ssd) утерлась ССД 200Г размером, где ниразу больше 10Г одновременно занято и небыло.. но и трима ниразу небыло, т.к рейд контроллер и он ни в JBOD ни как еще трим не пропускает. теперь там 500, но даже посмотреть то нельзя сколько натерло.... 500Г ССД под базой от забикса утерлась в 100% через год и пару месяцев, потом резко снизили объемы записи и вот уже прошло еще полтора года и теперь там 170%.. как бы от забикса принято решение отказываться. помрет, вот и откажемся :) Но пока работает. Вставить ник Quote
rm_ Posted May 18, 2018 Posted May 18, 2018 2 hours ago, st_re said: Но если ССД большая и свободного места много, то fstrim ставить раком будет довольно на долго систему Зависит ещё от ФС. Ext4 например запоминает уже тримнутые области (discard'ом или fstrim), и при повторных вызовах fstrim их больше не тримает. A Btrfs не запоминает. Не знаю насчёт XFS/JFS. Вставить ник Quote
st_re Posted May 18, 2018 Posted May 18, 2018 xfs, судя по времени трима, тримает все свободное всегда.. Вставить ник Quote
rm_ Posted May 19, 2018 Posted May 19, 2018 12 hours ago, st_re said: судя по времени Можно смотреть fstrim -v, на Ext4 при повторных вызовах сразу же после первого (и без записи на ФС) она возвращает "0 байт trimmed". А на других ФС всегда полное кол-во свободного места (и дольше, конечно). Вставить ник Quote
st_re Posted May 19, 2018 Posted May 19, 2018 Там столько по времени на большой почти пустой ссд, чт даже сомнений не вызывало... ну да, вот прямо сейчас 2 раза подрял. xfs $ sudo fstrim -v -a /home: 286,6 GiB (307678965760 bytes) trimmed $ sudo fstrim -v -a /home: 286,6 GiB (307677859840 bytes) trimmed Вставить ник Quote
megahertz0 Posted May 21, 2018 Author Posted May 21, 2018 Собрал в общем схему с 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. На запись все примерно так же. Вставить ник Quote
rm_ Posted May 21, 2018 Posted May 21, 2018 19 minutes ago, megahertz0 said: По крайней мере на Debian 7 и ядре 3.2.68-1. Таки да, это добавили с ядра 3.7: https://kernelnewbies.org/Linux_3.7#Block Вставить ник Quote
st_re Posted May 21, 2018 Posted May 21, 2018 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 ??? (применяется при загрузке) Вставить ник Quote
edo Posted May 21, 2018 Posted May 21, 2018 В 5/18/2018 в 21:38, st_re сказал: Наши тесты говорят, что для всех нашиих надо... скорость записи просаживается через некоторе время, если трим не делать. Когда сделаешь, снова ровно. :) речь именно про серверные диски? Вставить ник Quote
st_re Posted May 21, 2018 Posted May 21, 2018 Ну у производителя заявлялось, что серверное... но, честно, сэкономили и ничего сильно дорогого не брали, больно на требуемых объемах из бюджета вываливались. Скорее всего бывает лучше. Я же там написал, "для наших" :) В общем я имел в виду, что перед запуском в продакшн тестировать надо на вашй нагрузке ваши ССД, а не проспекты читать. Если тесты покажут, что трим не нужен, то слава кпсс... А вот если производитель наобещает горы золотые, то их, внезапно, может не оказаться там... Сюрприз будет. Вставить ник Quote
rm_ Posted May 22, 2018 Posted May 22, 2018 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 Вставить ник Quote
snvoronkov Posted May 22, 2018 Posted May 22, 2018 1 час назад, rm_ сказал: А в данном случае таких препятствий нет, для Debian 7 штатно доступно более новое ядро 3.16: Backports - это не совсем штатно. Даже, наверное, совсем не штатно. Вставить ник Quote
rm_ Posted May 22, 2018 Posted May 22, 2018 38 minutes ago, snvoronkov said: Backports - это не совсем штатно. Даже, наверное, совсем не штатно. Штатно enough :), на порядок штатнее чем собирать самому. Вставить ник Quote
megahertz0 Posted May 24, 2018 Author Posted May 24, 2018 Вот какой итог получается. Обновил систему на 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 до дисков. Вставить ник Quote
st_re Posted May 24, 2018 Posted May 24, 2018 2 часа назад, megahertz0 сказал: Похоже и правда blktrace -d /dev/sda -a discard -o - | blkparse -i - посмотрите, долетает ли до sda.. ну или записать кучу заранее известного мусора,найти её физически на sdX чтобы она DD отдавалась, стереть файл, сказать трим, сбросить кеши (echo 1 > /proc/sys/vm/drop_caches) и почитать оттуда же.. на большинстве SSD приедут нули, если трим сработал.. или тоже самое что было записано, если не сработал.. Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.