Re: Нумерация дисков
Evgueni Belenkov wrote: Метки проще однако и запутаться тяжелее. Проще - да, хотя uuid ничем не сложнее... а вот когда подключаешь к системе где корень к примеру с меткой ROOT (типичный случай для какой нибудь ФЕДИ) диск от другой аналогичной системы, на котором имеется раздел с такой же меткой - а ну ка, загрузись!, получается :-) Верно подмечено. Когда в общей системе есть несколько однотипных RedHat'ов, менять диски между серверами или просто подключение к другому серверу, иногда приводит к довольно интересным результатам, так как в системе оказываются диски с одинаковыми метками. И это нужно учитывать, выбирая метки в качестве идентификатора. -- maxym If it looks like a duck and quacks like a duck - it's a duck. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Нумерация дисков
On 2008.11.21 at 16:03:38 +0300, Evgueni Belenkov wrote: >20 ноября 2008 г. 22:24 пользователь Покотиленко Костик ><[EMAIL PROTECTED]> написал: > > Метки проще однако и запутаться тяжелее. > >Проще - да, хотя uuid ничем не сложнее... а вот когда подключаешь к Как ничем? Метки для всего десятка своих разделов я запомнил раньше чем в файловые системы записал. А десяток uuid-ов упомнить - гораздо сложнее. >системе где корень к примеру с меткой ROOT (типичный случай для какой >нибудь ФЕДИ) диск от другой аналогичной системы, на котором имеется >раздел с такой же меткой - а ну ка, загрузись!, получается :-) Есть такой эффект. Правда, для меня не слишком актуален. У меня в этой машине имеется hotpluggable ATA интерфейс, соотвтественно чужие диски будут подключаться без перезагрузки. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Нумерация дисков
20 ноября 2008 г. 22:24 пользователь Покотиленко Костик <[EMAIL PROTECTED] > написал: > > Метки проще однако и запутаться тяжелее. > Проще - да, хотя uuid ничем не сложнее... а вот когда подключаешь к системе где корень к примеру с меткой ROOT (типичный случай для какой нибудь ФЕДИ) диск от другой аналогичной системы, на котором имеется раздел с такой же меткой - а ну ка, загрузись!, получается :-) -- С уважением, Евгений [EMAIL PROTECTED]
Re: Нумерация дисков
On 2008.11.21 at 15:06:15 +0300, Иван Лох wrote: > А, чем Вам by-path не угодил? Тем что строки в fstab длиннее экрана получаются. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Нумерация дисков
On Thu, Nov 20, 2008 at 03:24:13PM +0300, Victor Wagner wrote: > On 2008.11.20 at 00:31:41 +0300, Evgeniy M. Solodookhin wrote: > > |(всякие /dev/dsk/by_uuid тут не помогут, поскольку в момент загрузки в > > |кардридере ничего нету, и никаких uuid там нет) > > почему вы так думаете ? > > Потому что проверил: > > ls /dev/disk/by-uuid/|wc -l > 9 > ls /dev/disk/by-path|wc -l > 18 А, чем Вам by-path не угодил? > Ну нету uuid у пустых слотов кардридера, нету. > > По такой записи абсолютно невозможно сказать ни на каком диске находится > данный раздел, ни в какой части этого диска он расположен. by-path -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Нумерация дисков
В Чтв, 20/11/2008 в 15:24 +0300, Victor Wagner пишет: > On 2008.11.20 at 00:31:41 +0300, Evgeniy M. Solodookhin wrote: > > второй способ - вписать нужный uuid при создании фс. > > а если вопрос в миграции - uuid переползет на новый диск и ничего > > переписывать не нада будет. > > Лучше уж тогда метки, а не uuid-ы. Метки они по определению > удобочитаемы. Я на метках остановился, те же грабли но читабельно. > > |То же самое касается /dev/disk/by_path. Все там хорошо, но не дай бог > > |PCI-адрес контроллера сменится. > > ну ето уже извращение. > > Почему извращение? При смене материнской платы PCI-адрес контроллера > сменится только так. А материнская плата обычно меняется по факту > сгорания предыдущей, т.е. в жестком цейтноте. Метки проще однако и запутаться тяжелее. -- Покотиленко Костик <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Нумерация дисков
> То же самое касается /dev/disk/by_path. Все там хорошо, но не дай бог > PCI-адрес контроллера сменится. Когда меня колбасило с пятью винчестерами на трех SATA контроллерах, я остановился на by_path. Да, включая fstab. Некрасиво, но работало. Лучшего способа я не нашел. Через udev развести их было было нельзя (я не нашел такого способа). P.S. Хотели, видимо, как лучше, а получилось как обычно. -- Best regards, Aleksey Cheusov. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Нумерация дисков
On 2008.11.20 at 00:31:41 +0300, Evgeniy M. Solodookhin wrote: > |(всякие /dev/dsk/by_uuid тут не помогут, поскольку в момент загрузки в > |кардридере ничего нету, и никаких uuid там нет) > почему вы так думаете ? Потому что проверил: ls /dev/disk/by-uuid/|wc -l 9 ls /dev/disk/by-path|wc -l 18 Ну нету uuid у пустых слотов кардридера, нету. > и в фстаб: > UUID="bee80c3c-4f0e-4bc3-a003-56f7f06a1d2d" /media/massive reiserfs > defaults,notail По такой записи абсолютно невозможно сказать ни на каком диске находится данный раздел, ни в какой части этого диска он расположен. > ни разу при смене ядер за последний год ни нумерация ни > > |Каким-то образом сделать, чтобы модуль usb_storage инициализировался > |заведомо не раньше, чем распознается второй sata-диск? > | > думаю, стоит в карте дисков груба навести порядок: > /boot/grub/device.map Это вряд ли. Во-первых, это касается только тех дисков, с которыми работает grub, во-вторых, ядро при назначении os objects его уж точно не читает. И вообще у меня там единственная строчка hd(0) /dev/sda > |Использование /dev/disk/by_id в принципе возможно, но > |1. Приведет к нечитаемости fstab > вполне читабельно. особенно с комментариями. да и строк там немного. У меня и так на экран еле влезает - 22 строки. И самые длинные из них (как раз те, которые для кардридера) по ширине больше 80 символов, да еще и с табуляцией. Это с крайне короткими именами устройств. > второй способ - вписать нужный uuid при создании фс. > а если вопрос в миграции - uuid переползет на новый диск и ничего > переписывать не нада будет. Лучше уж тогда метки, а не uuid-ы. Метки они по определению удобочитаемы. > > | > |То же самое касается /dev/disk/by_path. Все там хорошо, но не дай бог > |PCI-адрес контроллера сменится. > ну ето уже извращение. Почему извращение? При смене материнской платы PCI-адрес контроллера сменится только так. А материнская плата обычно меняется по факту сгорания предыдущей, т.е. в жестком цейтноте. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Нумерация дисков
On 2008.11.20 at 02:07:33 +0500, Murat D. Kadirov wrote: > 23:14 Wed 19 Nov, Victor Wagner wrote: > > какой именно из документов в /usr/share/doc/udev читать? > > (всякие /dev/dsk/by_uuid тут не помогут, поскольку в момент загрузки в > > кардридере ничего нету, и никаких uuid там нет) > > http://www.reactivated.net/writing_udev_rules.html К сожалению, не увидел там описания, как можно сделать так, чтобы данный девайс с USB= /dev/sdb не занимал Как создать симлинки вида /dev/card/cf /dev/card/mmc etc для слотов кардридера - увидел. Но это не единственное, что мне нужно. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Нумерация дисков
On Wed, Nov 19, 2008 at 11:14:14PM +0300, Victor Wagner wrote: > Каким-то образом сделать, чтобы модуль usb_storage инициализировался > заведомо не раньше, чем распознается второй sata-диск? > Ugly hack но вполне себе рабочий: сгенерить initrd без usb_storage. А вообще, использовать MODULES=list в initramfs.conf (указав те модули, которые реально нужны для монтирования корня) достаточно удобно. Без модулей для USB/сети он отрабатывается быстрей (для просыпания из hibernate весьма актуально). -- WBR, Dmitry signature.asc Description: Digital signature
Re: Нумерация дисков
,-[Wed, Nov 19, 2008 at 23:14 +0300, Victor Wagner:] |Имеется машина, на которой два SATA-диска и встроенный USB-кардридер. |Пока стояло на ней ядро 2.6.22 давным-давно выкачанное из бэкпортов, все |было нормально. | |Диски были sda и sdb, а четыре дырки в кардридере - от sdc до sdf. |Сапгрейдившись до lenny, решил заодно и ядро сапдейтить до текущего |2.6.26. | |И при загрузке машина вылетела в single-user, не сумев выполнить fsck на |sdb2. при записи по uuid в fstab fsck действует весьма адекватно. |(всякие /dev/dsk/by_uuid тут не помогут, поскольку в момент загрузки в |кардридере ничего нету, и никаких uuid там нет) почему вы так думаете ? там есть uuid дисков, имеющихся в наличии. сата, к примеру. | у меня помогает именно uuid и в опциях загрузки ядра (!) kernel /boot/vmlinuz-2.6.27.6-di root=UUID=4af75130-1e38-4e69-b53b-409ed2993117 ro и в фстаб: UUID="bee80c3c-4f0e-4bc3-a003-56f7f06a1d2d" /media/massive reiserfs defaults,notail ни разу при смене ядер за последний год ни нумерация ни |Каким-то образом сделать, чтобы модуль usb_storage инициализировался |заведомо не раньше, чем распознается второй sata-диск? | думаю, стоит в карте дисков груба навести порядок: /boot/grub/device.map у меня как то там очень даже сборная солянка была. и тоже странно все грузилось. http://www.gnu.org/software/grub/manual/html_node/Device-map.html |Использование /dev/disk/by_id в принципе возможно, но |1. Приведет к нечитаемости fstab вполне читабельно. особенно с комментариями. да и строк там немного. |2. Если какой-нибудь из дисков сдохнет и будет заменен на аналогичный |от другого производителя (или просто сапгрейжен на больший) - умучаюсь |fstab редактировать. замените один uuid на другой. дело пяти секунд, поверьте человеку, перемигрировавшему между десятком дисков за последние полгода (плановая замена и расширение виртуальной жилплощади). второй способ - вписать нужный uuid при создании фс. а если вопрос в миграции - uuid переползет на новый диск и ничего переписывать не нада будет. | |То же самое касается /dev/disk/by_path. Все там хорошо, но не дай бог |PCI-адрес контроллера сменится. ну ето уже извращение. -- __ mpd status: [playing] Kingdom Come - Cold Ground ** * jabber: [EMAIL PROTECTED] * * Registered linux user #450844* ** -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Нумерация дисков
Имеется машина, на которой два SATA-диска и встроенный USB-кардридер. Пока стояло на ней ядро 2.6.22 давным-давно выкачанное из бэкпортов, все было нормально. Диски были sda и sdb, а четыре дырки в кардридере - от sdc до sdf. Сапгрейдившись до lenny, решил заодно и ядро сапдейтить до текущего 2.6.26. И при загрузке машина вылетела в single-user, не сумев выполнить fsck на sdb2. Расследование показало что по каким-то причинам кардридер проинициализировался после первого диска, но до второго. В результате sdb стал одним из слотов кардридера, а диск - sdf. Загрузился обратно со старым ядром - все вернулось на свои места. Вот как бы теперь сделать так, чтобы и с новым ядром все было как раньше? Прописать udev-у, что кардридер нужно сажать на определенные буквы - какой именно из документов в /usr/share/doc/udev читать? (всякие /dev/dsk/by_uuid тут не помогут, поскольку в момент загрузки в кардридере ничего нету, и никаких uuid там нет) Каким-то образом сделать, чтобы модуль usb_storage инициализировался заведомо не раньше, чем распознается второй sata-диск? Диски вроде привешены к одному и тому же контроллеру. Во взяском случае, /dev/disk/by-path показывает следующее pci-:00:08.0-scsi-0:0:0:0 -> ../../sda pci-:00:08.1-scsi-0:0:0:0 -> ../../sdb pci-:00:02.1-usb-0:7:1.0-scsi-0:0:0:0 -> ../../sdc (первый слот кардридета) Использование /dev/disk/by_id в принципе возможно, но 1. Приведет к нечитаемости fstab 2. Если какой-нибудь из дисков сдохнет и будет заменен на аналогичный от другого производителя (или просто сапгрейжен на больший) - умучаюсь fstab редактировать. То же самое касается /dev/disk/by_path. Все там хорошо, но не дай бог PCI-адрес контроллера сменится. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
