Где смотреть совместимость SSD с Linux?

Насколько старое ядро? НЯЗ, проблемы были или есть только с каким-то навороченным trim от Samsung.

Насколько старое ядро? НЯЗ, проблемы были или есть только с каким-то навороченным trim от Samsung.

Ну, 3.10.17 хотя бы.

Разрешаю ставить SSD.
Раньше сдохнет мама-плата с причиндалами, нежели придёт в негодность шустрый SSD.

Заодно, придётся кернел пересобрать. Ибо для SSD требуется noop/deadline scheduler, в отличии от cfq для HDD, что стоит по умолчанию/default.

Enable the block layer --->
    IO schedulers --->
        Default I/O scheduler (выбрать noop/deadline)

Для проверки:
cat /sys/block/sda/queue/scheduler

Чтобы сменить скедулер нужно пересобирать ядро?

А если используется и HDD и SSD? По два штуки. Какой выбрать? Сейчас cfq, но в ядре есть все три.

скедулер

скедулер

В принципе, можно указать в правилах

blitz@inode /etc/udev/rules.d % cat /etc/udev/rules.d/60-schedulers.rules
#Set deadline scheduler for non-rotating and rotating disks
#ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"
#ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"
ACTION=="add|change", KERNEL=="sda", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="bfq"
ACTION=="add|change", KERNEL=="sdb", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"

Но пересобрать кернел с параметрами по умолчанию - лучше, ИМХО.

Смотри объяснение выше в топике.

Можешь пояснить? Ты таким образом для каждого диска назначаешь планировщик свой? Что такое ATTR{queue/rotational}==«0»? И можно ли то же самое сделать по UUID? Что-то я не уверен в sdX

Начнём с того, что кернел в данном случае - экспериментальный с патчами `много-потоковый bfq'.
Чтобы вас это не смущало, просто не обращайте внимание. Пока.

Таки да, для каждого девайса, будь то SSD или HDD - назначается сугубо отдельный планировщик/scheduler.

ATTR{queue/rotational}==«0» - означает невращаемый девайс, SSD.
ATTR{queue/rotational}==«1» - означает вращаемый девайс, HDD.

ATTR{queue/scheduler}=«bfq» - здесь можно задать один из трёх имеющихся в кернеле
Как, например - deadline для SSD и cfq для HDD.

Начнём с того, что кернел в данном случае - экспериментальный с патчами `много-потоковый bfq'.

Это я в курсе. Сам когда-то собирал с bfq

ATTR{queue/rotational}==«0» - означает невращаемый девайс, SSD.

Это назначение атрибута девайсу. Я правильно понимаю? А что его юзает? Сам bfq?

Т.е. мне как-то так надо:

ACTION=="add|change", KERNEL=="sda", ATTR{queue/scheduler}="noop"
ACTION=="add|change", KERNEL=="sdb", ATTR{queue/scheduler}="cfq"

А что насчет sdX? Вроде одни раньше менятся могли.

> lsblk -f
NAME   FSTYPE LABEL   UUID                                 MOUNTPOINT
sdd                                                        
└─sdd1 ext4           cd07c6b8-0143-4ec0-918b-ddf797db1274 /
sdb                                                        
└─sdb1 ext4           427d14fa-2262-48a0-943b-ea2448e25151 /home
sdc                                                        
└─sdc1 ext4   users   7a780315-e60d-4a68-9f17-bbff18505e3b /mnt/dev/@users
sda    ext4   storage f66a9673-4176-49d8-af1b-49558839df69 /mnt/dev/storage

sdd и sdb это как раз ssd'шки

ATTR{queue/rotational}==«0» - означает невращаемый девайс, SSD.

Это назначение атрибута девайсу. Я правильно понимаю? А что его юзает? Сам bfq?

Вовсе нет. Это идентификация девайса, что прописывается ручками.
То, что стоит в ЭВМ, и нужно для IO операций кернела.

bfq - умеет юзать SSD и HDD одновременно, в отличие от других планировщиков.

Да, твои правила ACTION технически грамотны и верны.

А что насчет sdX? Вроде одни раньше менятся могли. sdd и sdb это как раз ssd'шки

Правила udev - такой случай отклоняют и не рассматривают на сегодня.
Допускаю, что возможно и автоматически изменить /etc/udev/rules.d/60-schedulers.rules,
просканировав имеющиеся девайсы sdX и изменив соответственно правила в скрипте /etc/udev/rules.d/60-schedulers.rules.

И да, при этом придётся перегрузить ЭВМ или что там у вашенских.
Потому что bfq записано в строке инициализации кернела -scsi_mod.use_blq_mq=1, иначе не будет работать.

blitz@inode /boot/loader/entries % cat /boot/loader/entries/arch.conf
title		Arch Linux
linux		/vmlinuz-linux
initrd		/intel-ucode.img
initrd		/initramfs-linux.img
options		root=UUID=8adcea49-630a-4c4d-b106-024e133734e2 add_efi_memmap i915.fastboot=1 snd_usb_audio.index=0 snd-hda-intel.index=1 scsi_mod.use_blq_mq=1 rw

Это ясно.

В итоге сделал такое:

> cat /etc/udev/rules.d/60-schedulers.rules
ACTION=="add|change", KERNEL=="sda", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"
ACTION=="add|change", KERNEL=="sdb", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"
ACTION=="add|change", KERNEL=="sdc", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"
ACTION=="add|change", KERNEL=="sdb", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

> dmesg | grep noop
[    1.167600] io scheduler noop registered

Бери любой.

Для проверки:
cat /sys/block/sdX/queue/scheduler

Почему не сделать одним правилом?

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

Как теперь проверить что все ок?

cat /sys/block/sd*/queue/scheduler

Почему не сделать одним правилом?

Потому что нинадотак.
Десктоп приложения, в миг потеряют responsivness в операциях с heavy IO load.
Например, запусти компиляцию firefox с LTO и в моменте линковки xul - убедишься, что для каждого девайса нужен свой scheduler/планировщик.

Так у каждого и будет свой, у дисков - cfq, у ssd - noop.

Это только мне кажется, что твои мысли опережают твои же слова? ))

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

С чего вдруг они перестанут быть отдельными?

# lshw -c disk|grep 'product\|logical name'
       product: KINGSTON SS200S3
       logical name: /dev/sda
       product: KINGSTON SV300S3
       logical name: /dev/sdb
       product: WDC WD20EFRX-68E
       logical name: /dev/sdc
       product: WDC WD20EFRX-68E
       logical name: /dev/sdd
       product: WDC WD20EFRX-68E
       logical name: /dev/sde
       product: WDC WD20EFRX-68E
       logical name: /dev/sdf

# for i in {a..f} ; do echo -n sd$i: ; cat /sys/block/sd$i/queue/scheduler ; done
sda:noop [deadline] cfq 
sdb:noop [deadline] cfq 
sdc:noop deadline [cfq] 
sdd:noop deadline [cfq] 
sde:noop deadline [cfq] 
sdf:noop deadline [cfq] 

Отлично и вот теперь - как нужно!
И это сделано с тем правилом?

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

Отнюдь niet.

[23:39:29] alex@alex-desktop /home/alex (0)                                     
> cat /sys/block/sda/queue/scheduler
noop deadline [cfq] 
[23:39:38] alex@alex-desktop /home/alex (0)                                                                                                                                                                  
> cat /sys/block/sdb/queue/scheduler
[noop] deadline cfq 
[23:39:50] alex@alex-desktop /home/alex (0)                                                                                                                                                                  
> cat /sys/block/sdc/queue/scheduler
noop deadline [cfq] 
[23:39:54] alex@alex-desktop /home/alex (0)                                                                                                                                                                  
> cat /sys/block/sdd/queue/scheduler
noop deadline [cfq]

Похоже не пашет (((

Ну, очевидно, что у меня deadline, а не noop в правиле.

У тебя два раза sdb в правилах.

Таки пашет.
Задал для sda и sdc - вращаемый девайс с планировщиком cfq - и правило сработало.

> cat /etc/udev/rules.d/60-schedulers.rules
ACTION=="add|change", KERNEL=="sda", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"
ACTION=="add|change", KERNEL=="sdb", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"
ACTION=="add|change", KERNEL=="sdc", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"
ACTION=="add|change", KERNEL=="sdb", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

Зойчем ты пытаешься привязаться к именам устройств, когда тебя должно интересовать исключительно наличие шпинделя в них?

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

Ну, очевидно, что у меня deadline, а не noop в правиле.

Можно и мне, записаться к вашенским аутистам? ))

Если кернел проглотит такое - why not? Благодарю за интересное решение!

Это правило было написано для Suntechnic. Свое не стал копипастить, т.к. думал что это будет очевидно.

sd[a-z], и где они -отдельные планировщики, согласно твоего замысла ))

По совокупности параметров KERNEL и ATTR у тебя как раз исключительные планировщики выставятся.

Ну и решение унылое и «в лоб» ибо лишних линуксов под рукой для тестов нету

Есть у меня тест-кернел (с beck up) для такого случая.
Сделаю systemctl reboot и посмотрится в journalctl -xb | grep -Ei 'fail|error|not found'

Блин. Спасибо - пропарился. Но я уже поменял правила на

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

И спасибо тебе, blitz и dhameoelin за советы и помощь.

Теперь следующий вопрос - почему deadline, а не noop?

А это ты проверишь сам - что лучше на твоей аппаратуре - или deadline или noop.

Для эtого, есть специальный тест - https://github.com/ckolivas/interbench Запускается с отключённым DE и измеряет латентность и отзывчивость планировщиков/schedulers.

Можешь найти бинарник и дать компу полчаса на прохождение теста.
bfq - оказывается быстрей и отзывчивей. Неудивитильно.

== сравнение, = присваивание.

У deadline'а приоритет операций чтения над записью, у noop с одинаковым приоритетом. Для себя решил что лучше взять deadline.

для SSD требуется noop/deadline scheduler

Это неправда. Да и cfq уже давно прмемлимо оптимизирован как для HDD, так и для SSD

В теории - да. В кернеле 4.12.х
У ТС - 3.10.17. Не забываем об этом.

Тогда вариков нет - для sdd у меня это вообще система, а sdb хомяк - deadline само то.

== сравнение, = присваивание.

Да я то в курсе, но присвоение обычно тоже что-то возрващает. И это обычно true

У тебя два раза sdb в правилах.

Таки сделай, чтобы было 2 с половинкой - ну или хотя бы два с четвертью.
Ты же сможешь, правда?

ШТА?

Нормальное произношение, что не нравится?

https://en.wiktionary.org/wiki/scheduler

OMG, перепись неосиляторов udev ITT.

blitz, Suntechnic — всё написано в man udev, примеры готовых правил есть в /usr/lib/udev. Никаких «по UUID» или «не по UUID» не нужно, вас должно интересовать только значение атрибута queue/rotational. Просто пишете два правила, одно для HDD, второе для SSD. И как нужно упороться, чтобы подумать, что от количества правил как-то зависит поведение?

Кстати, вы знали, шедулер можно менять и в рантайме без всякого udev? :) Можно просто руками писать в /sys/block/sdX/queue/scheduler. udev делает то же самое, там нет никакой магии.

Кстати, каноничный вариант правил не угадал никто. Он таков:

ACTION!="remove", SUBSYSTEM=="block", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"
ACTION!="remove", SUBSYSTEM=="block", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

Благодарю за интересную информацию! brainstorming имеет место ))

примеры готовых правил есть в /usr/lib/udev

Действительно, есть правила на все случаи бинарной жизни компьютера
За исключением - `scheduler'. Ни в одном из exemplary правил нет и упоминания о самом существовании шедулера.

PS. Да, мы только и всегда учимся, и на годных примерах - made by example.
Как и на патчах Clear Linux Intel kernel.

Кстати, каноничный вариант правил не угадал никто.

Ну, мы в шпаргалки не подматривали)

Отношение разработчиков линукса к проблемам пользователей с SSD можно посмотреть здесь https://bugzilla.kernel.org/show_bug.cgi?id=195895

Можно увидеть в том логе, что инициализация ATA SSD девайсов идёт с задержкой в 6 секунд(!).
Нормально - не более 2 секунд: https://pastebin.com/0nn5VdQG
с таким кернелом `Linux inode 4.12.7-1-ARCH #1 SMP PREEMPT Mon Aug 14 15:09:58 CEST 2017 x86_64 GNU/Linux'

В винде то все ок, а от разрабов линукса слышно только молчание