Summary: | /etc/rc.d/scripts/idetune не настраивает sda | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Slava Dubrovskiy <dubrsl> |
Component: | startup | Assignee: | Alexey Gladkov <legion> |
Status: | ASSIGNED --- | QA Contact: | qa-sisyphus |
Severity: | enhancement | ||
Priority: | P3 | CC: | dd1email, evg, glebfm, grizlik78, ildar, ldv, legion, mike, vsu |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux |
Description
Slava Dubrovskiy
2009-05-27 16:44:15 MSD
Может быть есть смысл к UUID/LABEL каким-то привязываться, если нет разделения ide/sata/scsi? Или это не проблема? Что мешает сделать такое? Подозреваю, что банальная лень. Кстати, у _дисков_ не бывает UUID/LABEL. Плюс - надо запускать то же самое после resume. Знаю, что не бывает. Не знаю, как правильно идентифицировать (достаточно ли /dev/sd?). В особо клинических случаях их бывает /dev/sd[a-z]+, когда после sdz идёт sdaa, sdab, sdac и т.д. Но в таких случаях (multipath на внешних стораджах) смысла в hdparm уже мало. *** Bug 23864 has been marked as a duplicate of this bug. *** (В ответ на комментарий №2) > Кстати, у _дисков_ не бывает UUID/LABEL. Зато бывает /dev/disk/by-id/* (привязка к серийному номеру диска, в последних версиях udev ещё и к другой вариации на эту тему - WWN) и /dev/disk/by-path/* (тут получается привязка к порту контроллера, куда подключен диск, но номера шин PCI иногда могут меняться при добавлении/удалении других PCI-устройств). Про UUID/LABEL я имел ввиду что хочется чтобы настройки применялись к тому чему надо вне зависимости от того, как при загрузке разложится пасьянс буковок sdXX :-) Можно например так: http://git.altlinux.org/people/evg/packages/?p=startup.git;a=commitdiff;h=74625622028c31265445293bd1f5b52d10b2103b (требуется review). P.S.: откуда FIXED то? (В ответ на комментарий №8) > Можно например так: Поддержка только WWN оставляет за бортом не только PATA-диски, но и многие SATA-диски не самых последних серий. Вероятно, лучше брать просто имя ссылки из /dev/disk/by-id/*, чтобы можно было использовать любой доступный вариант. Там не только WWN, но и /dev/FOO можно указать (см. код). И даже нужно для всяких *-ROM. Всё подряд из /dev/disk/by-*/* не стал брать, потому что а) Было лень фильтровать оттуда лишь целые диски (без партиций и т.п.) и б) потому что не вижу смысла в привязке к месте на шине. (В ответ на комментарий №10) > Там не только WWN, но и /dev/FOO можно указать (см. код). И даже нужно для > всяких *-ROM. Однако имя в подкаталоге указать уже не получится (для некоторых других задач это тоже может быть проблемой - например, из-за /dev/cciss/cXdY и других устройств со "странными" именами). > Всё подряд из /dev/disk/by-*/* не стал брать, потому что а) Было > лень фильтровать оттуда лишь целые диски (без партиций и т.п.) Для WWN там разделы тоже есть (wwn-0x${WWN}-part${NUM}), поэтому при наличии желания фильтровать делать это придётся и для WWN. > и б) потому что не вижу смысла в привязке к месте на шине. Вот как раз /dev/disk/by-id/* привязывается к свойствам самого диска - чаще всего к serial. Привязка к месту на шине - это /dev/disk/by-path/*. Короче говоря, предлагаю как минимум заменить "/dev/disk/by-id/wwn-0x$i" на "/dev/disk/by-id/$i". Ещё можно ввести в сам файл переменную DEVICE, позволяющую явно указать любое имя устройства (в таком варианте неплохо было бы перейти на чтение файлов по маске вида *.conf, либо как минимум явно игнорировать имена вида *~, *.rpm*). > > Там не только WWN, но и /dev/FOO можно указать (см. код). И даже нужно для > > всяких *-ROM. > Однако имя в подкаталоге указать уже не получится (для некоторых других задач > это тоже может быть проблемой - например, из-за /dev/cciss/cXdY и других > устройств со "странными" именами). Виноват, не подумал об этом. > > Всё подряд из /dev/disk/by-*/* не стал брать, потому что а) Было > > лень фильтровать оттуда лишь целые диски (без партиций и т.п.) > Для WWN там разделы тоже есть (wwn-0x${WWN}-part${NUM}), поэтому при наличии > желания фильтровать делать это придётся и для WWN. Наверно, я неясно выразился. Под "фильтровать" я имел ввиду как раз исключение из рассмотрения всех wwn-0x${WWN}-part${NUM} и т.п., т.к. hdparm ведь требует имя целого диска, как я понимаю, и партиции ему ни к чему. > > и б) потому что не вижу смысла в привязке к месте на шине. > Вот как раз /dev/disk/by-id/* привязывается к свойствам самого диска - чаще > всего к serial. Привязка к месту на шине - это /dev/disk/by-path/*. Я знаю про by-path. Про привязку с шине имею ввиду и by-path/* и by-id/{ata,scci}* (может, конечно, ошибаюсь). > Короче говоря, предлагаю как минимум заменить "/dev/disk/by-id/wwn-0x$i" на > "/dev/disk/by-id/$i". сделаю > Ещё можно ввести в сам файл переменную DEVICE, позволяющую > явно указать любое имя устройства (в таком варианте неплохо было бы > перейти на чтение файлов по маске вида *.conf, либо как минимум явно > игнорировать имена вида *~, *.rpm*). Я так и делал в первых вариантах коммита, но у меня не было DEVICE, поэтому я счёл это бессмысленным. Сделаю. (В ответ на комментарий №12) > Про привязку с шине имею ввиду и by-path/* и > by-id/{ata,scci}* (может, конечно, ошибаюсь). У by-id есть некоторая привязка к типу драйвера - но, например, ссылки ata-* должны создаваться при использовании и старых драйверов IDE, и новых libata (работающих через scsi), причём на современных ядрах они для этих режимов должны совпадать (хотя со старыми версиями ядер и udev в этом месте были проблемы, связанные с обрезанием модели до длины, поддерживаемой SCSI). Вот ссылки scsi-* будут действительно создаваться только при использовании libata. Хотя случай перетыкания диска в USB-SATA box действительно обработан не будет, поскольку для USB используются другие имена (но для hdparm это всё равно неактуально). (In reply to comment #11) > Однако имя в подкаталоге указать уже не получится (для некоторых других задач > это тоже может быть проблемой - например, из-за /dev/cciss/cXdY и других > устройств со "странными" именами). А этим hdparm и не припарка: # hdparm -d 1 /dev/ida/c0d0 /dev/ida/c0d0: setting using_dma to 1 (on) HDIO_SET_DMA failed: Invalid argument > > устройств со "странными" именами).
> А этим hdparm и не припарка:
Тем не менее, лучше сделать чтобы припарку можно было накладывать в любом месте.
Новый вариант: http://git.altlinux.org/people/evg/packages/startup.git?p=startup.git;a=commitdiff;h=04c6bb085434add7b310a5289615d2d14693fd61 (требуется review). Пробел упустил и ещё кой-чего, см.: http://git.altlinux.org/people/mike/packages/?p=startup.git;a=commitdiff;h=c1598db4ef28e95e6bd4c744cd67ec47808fb151 Проверил на домашней SATA-only системе -- пришлось переименовать один из /etc/sysconfig/harddisk/hd* в sdd.conf и выкинуть MULTIPLE_IO с EIDE_32BIT, осталось: home:~> cat /etc/sysconfig/harddisk/sdd.conf LOOKAHEAD=1 EXTRA_PARAMS=-qq и на ноуте с IDE и pad:~> cat /etc/sysconfig/harddisk/sda.conf LOOKAHEAD=1 EXTRA_PARAMS=-B255 Вердикт: живое, но про необходимость переименования файлов хорошо бы нарисовать отдельную предупреждалку в %post и упомянуть в %changelog. Могу дописать когда-нибудь после субботней конференции (сейчас жду человека). Возможно, сюда же будет смысл подкинуть sdparm (тоже потом). PS: если мержить, то предлагаю следом сделать git mv startup/rc.d/scripts/{idetune,hdparm} subst 's,idetune,hdparm,' rc.d/rc.sysinit git commit -am 'renamed scripts/idetune to scripts/hdparm' %post/%changelog это уже к маинтайнеру. Упомянуть необходимость переименования в .conf надо. vsu, ldv? ping? 2ldv: Так чего же, всё таки, хочется? Вопрос: если каталог /etc/sysconfig/harddisk/ пуст, а файл /etc/sysconfig/harddisks не пуст, применять содержимое последнего ко всем дискам? Раньше, в старом scripts/idetune, было именно так. В вашей версии /etc/sysconfig/harddisks применяется только для дисков, указанных в /etc/sysconfig/harddisk/. Пожалуй, при прочих равных лучше бы оставить старую семантику. Да. (In reply to comment #23) > Пожалуй, при прочих равных лучше бы оставить старую семантику. Тогда вопрос, для каких блочных устройств применять /etc/sysconfig/harddisks? Для всех /sys/block/*/device? Если не для всех, то для каких? Имеет ли смысл сейчас применять какой-то тюнинг единообразно ко всем блочным устройствам? Смотри: - ноутбук: только sda (HDD) - десктоп: fd0, sd[a-h], sr0 => флопик, 4HDD, card reader, писалка - сервер: sd[a-i], sr0 => SSD, 8HDD, писалка Из них во всех случаях можно спокойно исключить fd* и sr*; sd* для случая десктопа скорее можно тюнить однообразно; для случая сервера скорее можно полагаться на то, что уж если оказалась необходимость тюнинга и сисадмин в курсе про /etc/sysconfig/harddisk*, то в случае различных типов дисков он это учтёт. (In reply to comment #26) > Из них во всех случаях можно спокойно исключить fd* и sr*; А как это лучше сделать? В любом случае hdparm имеет смысл применять только к /dev/disk/by-id/ata-* (там, правда, мешаются разделы, ну и могут быть конфликты из-за CD-приводов без серийного номера вида /dev/disk/by-id/ata-Optiarc_DVD_RW_AD-7173S). Можно сделать что-то типа /sbin/udevadm trigger --dry-run --verbose --subsystem-match=block \ --property-match=ID_ATA=1 --attr-nomatch=partition=\* (но --attr-nomatch=partition=\* требует ядра >= 2.6.28). Либо фильтровать по именам устройств: /sbin/udevadm trigger --dry-run --verbose --subsystem-match=block \ --property-match=ID_ATA=1 --sysname-match='*[a-z]' (но при этом отфильтруются и sr*). Впрочем, потом всё равно придётся переводить полученные таким образом пути sysfs в имена устройств (например, вызовами udevadm info). Тогда вообще напрашивается udev rule. (In reply to comment #29) > Тогда вообще напрашивается udev rule. Да, это единственный разумный способ тюнить диски, подключаемые позже во время работы системы. (В ответ на комментарий №29) > Тогда вообще напрашивается udev rule. В Debian именно так и сделано: ACTION=="add", SUBSYSTEM=="block", KERNEL=="[sh]d[a-z]", RUN+="/etc/init.d/hdparm hotplug" Правильная версия скриптов: http://patch-tracker.debian.org/patch/debianonly/view/hdparm/9.32-1 (в том, что лежит в апстримном hdparm, имя устройства из hdparm.conf просто сравнивается с DEVNAME, без возможности использования /dev/disk/by-id/*). Впрочем, формат конфигурации там всё равно не имеет ничего общего с нашим. на эту тему прошу сделать аудит этого: /usr/lib/pm-utils/power.d/harddrive . Прошу учесть, что пакет pm-utils стоит у большинства desktop-пользователей. |