Очень интересно!

значит не меняется

Нет это значит, что ты везучий ССЗБ

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html...

Я в курсе что так не правильно. Создавал 10 лет назад и не лазил туда больше. Сам сейчас это с удивлением обнаружил.

То что в курсе - молодец, а то многие тут не верят.
Но и 10 лет назад это тоже было не правильно.

Видать диск с системой удачно всегда инициализируется первым. У меня такой расклад сразу бы слетел.

молодец

Спасибо, для меня похвала очень важна!

10 лет назад это тоже было не правильно.

Срок давности этого преступления уже истек.

Исправил в fstab /dev/sdb1 на UUID, одобряешь?

Похоже на то, что в некоторых случаях, как у nvl, просто вот так работает железо, что один диск всегда отзывается раньше другого, и они годами могут думать (это не про nvl), что всё по-прежнему, пока не поменяется железо.

Однако у utanho диски пляшут, но он так и стоит на своём.

Этот диск использовался практически с каждой загрузкой (на ночь выключаю), там в том числе и директория под загрузку торрентов. Так что «тестирование» было «полным».

У меня почему-то диску с «мусором» система любит назначать sda, но иногда, сильно редко, отдаёт sda системному, никаких закономерностей не замечено, рандом.

Ну, разумеется, из-за кучки тех у кого «hundreds of disks» страдать должны даже домашние юзеры с двумя-тремя. Типичный ляликс.

ИЧСХ, для асинхронного сканирования шин SCSI существует параметр scsi_mod.scan=async. А для устройств это почему-то неотключаемый дефолт — жрите что дают.

ЗЫ. Причём, падла, LVM от того же Редхата до сих пор использует имена томов /dev/sd* и менять здесь никто ничего не собирается. Зоопарк, мля.

Просто «non-persistent names in the form of /dev/sd» не означает что они должны имитировать генератор случайных чисел и при каждой загрузке меняться.
Это всего лишь не гарантирует то что они будут постоянными.
А так да, в зависимости от сочетания железа и софта, оно вполне себе может не меняться годами.

LVM от того же Редхата до сих пор использует имена томов /dev/sd*

Где-то в документации Редхата было, что /dev/sd* нужен т.к. эти имена используются ядром.

А что ты вообще этим вопросом озадачился? Диск монтируется у тебя по UUID, так какая тебе разница sdb или sda под капотом?

страдать

Страдают только нейроразнообразные товарищи, которые за 20 лет не удосужились fstab поменять и продолжают упорствовать, ожидая что этот «баг» исправят.

LVM

Вообще никак не подвержен этой «проблеме»

Ну, разумеется, из-за кучки тех у кого «hundreds of disks» страдать должны даже домашние юзеры с двумя-тремя. Типичный ляликс.

А что делать!? Какие обои и иконки не рисуй, а внутренне линукс всё равно пока ещё гусеничный трактор для работы в суровых условиях крайнего севера.

А что ты вообще этим вопросом озадачился?

Очень интересно! (комментарий)

Я допускаю, что в новых версиях udev что-то допилили

udev не присваивает имена устройствам. Это делает ядро. Возможно в ядре и добавили фичу «переименование блочного устройства» как это сделано для сетевых адаптеров, но это вряд ли.

Поэтому если у тебя несколько дисков SATA/SCSI/USB то в зависимости от скорости определения и отклика оных у тебя будут меняться имена устройств.

ПыСы: полагаются на имена блочных устройств только неадекваты. Чуть более адекваты могут полагаться на путь - но и на них найдется хитрый болт. Только partition UUID / filesystem UUID дают действительно предсказуемый результат.

Так поссылке которую дал arax все объяснено:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_file_systems/assembly_overview-of-persistent-naming-attributes_managing-file-systems

Traditionally, non-persistent names in the form of /dev/sd(major number)(minor number) are used on Linux to refer to storage devices. The major and minor number range and associated sd names are allocated for each device when it is detected. This means that the association between the major and minor number range and associated sd names can change if the order of device detection changes.

Such a change in the ordering might occur in the following situations:

The parallelization of the system boot process detects storage devices in a different order with each system boot.

A disk fails to power up or respond to the SCSI controller. This results in it not being detected by the normal device probe. The disk is not accessible to the system and subsequent devices will have their major and minor number range, including the associated sd names shifted down. For example, if a disk normally referred to as sdb is not detected, a disk that is normally referred to as sdc would instead appear as sdb.

A SCSI controller (host bus adapter, or HBA) fails to initialize, causing all disks connected to that HBA to not be detected. Any disks connected to subsequently probed HBAs are assigned different major and minor number ranges, and different associated sd names.

The order of driver initialization changes if different types of HBAs are present in the system. This causes the disks connected to those HBAs to be detected in a different order. This might also occur if HBAs are moved to different PCI slots on the system.

Disks connected to the system with Fibre Channel, iSCSI, or FCoE adapters might be inaccessible at the time the storage devices are probed, due to a storage array or intervening switch being powered off, for example. This might occur when a system reboots after a power failure, if the storage array takes longer to come online than the system take to boot. Although some Fibre Channel drivers support a mechanism to specify a persistent SCSI target ID to WWPN mapping, this does not cause the major and minor number ranges, and the associated sd names to be reserved; it only provides consistent SCSI target ID numbers.

боюсь дело не в федоре. Кривые сука биосы, они такие. Похоже пора переходить на монтировние по UUID, иначе беда.

ещё интереснее услышать как так получается

SSD + HDD, один стартует гарантированно быстрее другого и получает букву первым, не?

У меня два ssd, один чуть новее и может быть чуть быстрее, но фирма одинаковая у них, и вот этот сильно чаще получает sda, хз почему.

Я победил?

Я ни разу не видел разрывов в именовании дисков, и для меня довольно очевидно, что при недоступности sdb бывший sdc займёт его место. Собственно, никто не гарантирует, что диски инициализируются всегда за одно и то же время, поэтому не вижу причин думать, что имена они получают одинаково.

Когда-то было иначе – воткнул диск, поставил систему, и был он то ли hda, то ли sda, я уже не помню. Потом втыкай ещё диски и никаких проблем, системный всегда оставался одинаковым, поэтому можно было в fstab так и писать.

Потом стали по uuid делать, и я уже не заметил, когда всё изменилось.

Или я изначально неправильно себе это представлял и мне просто везло, что всё работало 😁

Думаю да.

1 nvme, 2 sata hdd.

Видать nvme быстрее всех обнаруживает ядро, а вот hdd могут меняться местами.

UUID=-cut-

А что, я извиняюсь, UUID опасно палить? Могут увести?

Видать nvme быстрее всех обнаруживает ядро

Ну было бы странно, если бы у одного nvme менялось название, у них же совсем другое именование: nvme0n1.

Точно, тогда совсем отпадает. А хдд можешь по sd* прописать в fstab, если уверен, что они не меняются 😁

Я бы может так и сделал, но система на nvme, соответственно ничего не меняется, да еще и на lvm, т.е. монтируется по /dev/mapper/*. И компьютер у меня не перезагружается иногда неделями, чтобы эксперимент имел какую-то приличную выборку.

И компьютер у меня не перезагружается иногда неделями, чтобы эксперимент имел какую-то приличную выборку.

Если ты считаешь, что не меняется, то пропиши и забудь, а потом когда-нибудь, если слетят хдд, расскажешь 😎

Да почему, раз написано в ченджлоге ведра, значит меняются, наверное. Возможно потом придумали что-то, что если дисков мало – не менять. В любом случае понятно, что на неизменность полагаться не стоит, даже если оно сейчас и не меняется.

Уникакальные вещи всегда не стоит палить. Хрен его знает как это может аукнуться. Например, помню как программеру эстонскому не дали визу, так как где-то в сети он назвал нерга негром. По uuid можно например идентифицировать юзера на разных форумах. Prism/Google наверняка это делает автоматически наполняя твое досье.

Так nvme в системе может быть тоже больше одного и будет он то. Nvme0, то nvme1

Описанное не наблюдал очень много лет. Но не на Федоре.

но я марсианам не очень доверяю

Илона на тебя нет)

И что же в этом тексте объясняется? Ну кроме варианта с параллельной загрузкой.

SSD + HDD

Мой вариант. Рандом.

Я победил?

Влажные фантазии.

Для начала, давайте попробуем разобраться, чем отличается /dev/sdX и by-path.

Ключевая фраза: «change in the ordering might occur». Т.е. Redhat не гаранитрует неизменность, а далее по тексту прямо пишет «These reasons make it undesirable to use the major and minor number range or the associated sd names when referring to devices, such as in the /etc/fstab file» что собственно papin-aziat и хотел выяснить.

Redhat не гаранитрует неизменность

Не гарантирует, однако в Федоре всё работает.

У меня тоже работало. Но это не правило, а часный случай. У меня например скорее всего инициализоровалась всегда ссдшка быстрее чем жосткий. А у папина-азиата 2 ссд.

чем отличается /dev/sdX и by-path

Хз, но оба не надёжные, поэтому идут нафиг.

У меня например скорее всего инициализоровалась всегда ссдшка быстрее чем жосткий

У меня ССД и ХДД. Инициализируются как попало. Но я об этом не знал, пока не слез с генты и не начал тыкать палкой в дебиан и сюсю.

пока не слез с генты и не начал тыкать палкой в дебиан и сюсю

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

Гента всё-таки что-то древнее, из эпохи неолита.

Опять влажные фантази любителя копролита?

Да где ты копролит-то нашёл?

названия /dev/sd* у дисков

Нафига? Православно делать /dev/disk/by-uuid/

Тред не читай, сразу отвечай. Одобряю!

У меня на десктопе старенькая федора с ядром 5.17.

2 Sata SSD + 2 Sata HDD

Названия дисков /dev/sd* не меняются.

Меня тут задолбало угадывать, какой из дисков сегодня какой, запилил:

alias sd='lsblk -AlSno KNAME,MODEL /dev/sd?'

(правда, если диски однотипные, надо будет добавить ещё какой-нито SERIAL, UUID или кому что нравится.)