В соответствии с каким алгоритмом Linux назначает буквы жестким дискам?

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

Я использую Ubuntu 16.04.4 LTS (Linux 4.4.0 -128 -универсальный i686 ).

Я использую спящий режим между ежедневными сеансами и подозреваю, что диск переназначается при выходе из спящего режима, хотя я не совсем в этом уверен. Обычно ему назначается /dev/sdc, и у меня есть USB-устройство чтения SD-карт, которое я оставляю подключенным, которому назначается /dev/sdd. Бывают случаи, когда я не могу читать или записывать на внешний диск. Когда это происходит, я обнаруживаю, что он был переназначен на /dev/sde. Одно из исправлений — просто перезагрузить ОС, и все вернется в норму, но я ищу исправление, в котором мне не нужно доходить до такой крайности.

Я обнаружил, что лучшее решение — сначала закрыть все приложения, которые обращаются к любому разделу на внешнем диске, включая все вкладки терминала, которые находятся в папке на разделе на внешнем диске. Если у меня есть приложение, в котором я внес изменения в файл, который находится на недоступном диске, необходимо сохранить файл в другой доступный раздел по двум причинам :1 ), чтобы данные сохранялись, и 2 )для разрыва связи с недоступным разделом.Затем я размонтирую раздел (s )с помощью

sudo umount /dev/sde

или любое другое назначение для всех разделов внешнего диска. Затем я перемонтирую все разделы (с )с

sudo mount -a

После этого я обнаружил, что ошибочный раздел теперь снова доступен любому приложению, даже если раздел по-прежнему назначен /dev/sde вместо ожидаемого /dev/sdc. Поскольку fstab работает с метками и монтирует эти разделы в папки, это переназначение не является проблемой. Кажется, мне приходится делать это два или три раза в месяц.

Мне интересно, хотя я использую метки для идентификации разделов, если mount сопоставляет метку с назначением буквы устройства, что и вызывает эту проблему. Точно сказать не могу... Просто в раздумьях.

Связанный вопрос (из автоматической боковой панели):Как предотвратить изменения /sda /sdb между загрузками?

Это гарантирует их назначение в том порядке, в котором они "прощупываются" (или "привязываются" )ядром.

Грег К.Х. выступает за то, чтобы не полагаться на этот приказ. Он любит приводить пример (реального! )Ужасно спроектированная материнская плата, которая повторно -устанавливает порядок PCI между последующими загрузками. Похоже, приведенный выше вопрос касается одного из таких примеров.

Загружаемые модули загружаются пользовательским пространством. udevраспараллеливается с использованием нескольких процессов и не гарантирует загрузку модулей в каком-либо конкретном порядке. Подобная распараллеливание инициализации может иметь реальные преимущества в производительности, поскольку функции инициализации модулей могут выполняться параллельно, и эти функции могут включать длительные задержки в ожидании оборудования.

В настоящее время можно предположить, что ядро ​​по умолчанию должно проверять встроенные -драйверы синхронно и, следовательно, в детерминированном порядке.

As of v4.2 the Linux kernel now sports asynchronous probe support

(по-видимому, эта функция используется ОС Google Chrome ).

https://www.do-not-panic.com/2015/12/linux-asynchronous-probe.html

https://kernelnewbies.org/Linux_4.2#Core

Основываясь на исторических сообщениях , вы могли бы также предположить, что такие усилия вызывают скептицизм/усталость, не в последнюю очередь со стороны Линуса. Основываясь на вышеизложенном, кажется, что какие бы усиленные проверки и/или яростные кричащие сообщения не стояли на пути объединения этого варианта.

Включение его для всего ядра -— это другой вопрос, поскольку «[некоторые] драйверы плохо работают с асинхронным зондированием из-за ошибки драйвера или неоптимальной организации драйвера». Может Линус не взорвался (? )в сообщении объединенной фиксации, в котором говорится, что «конечная цель — сделать зондирование асинхронным по умолчанию», но это только одно мнение, и оно не говорит нам, насколько хорошо оно продвинулось с версии 4.2.

What guarantees does Linux make regarding the mapping of device names to the physical hard drives?

Which rules does it use to map physical hard drives to files in /dev/?

Я не могу говорить о каждом дистрибутиве Linux, но могу рассказать о том, как это делает SUSE, в SUSE доступны следующие опции

крепление на

• имя устройства
• идентификатор устройства
• метка тома
• путь к устройству
• UUID

по имени устройства я бы сказалплохо , потому что это заставляет linux проверять аппаратное обеспечение и порядок , в котором он видит подключенные диски, это то, как он выполняет сопоставление с сда, сдб и так далее. Поэтому, если ваше загрузочное устройство и раздел называются sda, и вы просто меняете порядок дисков в съемных слотах (на сервере )или переключаете кабели sata на домашнем компьютере между двумя дисками, это нарушит ситуацию. Также по моему опыту (на серверах с 8, 16 или 24 отсеками для дисков )часто происходит обратное, что слот для диска 0 НЕ сопоставляется с sda... если у вас было 3 диска, то слот 2 - это sda, слот 1 sdb и слот 0 sdc. И добавьте любое временное оборудование, которое отображается как /dev/sdaи сдвигает диски вниз на букву, нарушая ситуацию. Но я скажу, что этот метод хорош при настройке диска операционной системы с золотым образом, который вы планируете клонировать... вам не нужно беспокоиться об изменении идентификатора жесткого диска или WWN на новом диске, по крайней мере, некоторое время... если это единственный диск в системе, вполне вероятно, что он всегда будет отображаться как sda.

FSTAB syntax:**
/dev/sdc2 / EXT3 acl,user_xattr 1 1
/dev/sdc1 /boot/efi VFAT
/dev/sdb1 /data XFS defaults 1 0

по идентификатору устройства - это то, что я всегда использую, потому что оно решает в основном все проблемы, упомянутые для «по имени устройства», и это хорошо работало для меня на протяжении многих лет, почти все. После того, как монтирование настроено по идентификатору устройства, диски просто должны присутствовать или подключаться.Если диски перемещаются или новое оборудование отображается как /dev/sd?, это не влияет ни на что, что было настроено ранее.

FSTAB syntax:
/dev/disk/by-id/scsi-35000aab12345a30-part2 / EXT3 acl,user_xattr 1 1
/dev/disk/by-id/scsi-35000aab12345a30-part1 /boot/efi VFAT
/dev/disk/by-id/scsi-3600404abc123def456-part1 /data XFS defaults 1 0

by UUID {универсальный уникальный идентификатор} Я думаю, что это тоже хороший вариант, он работает так же, как «по устройству -id», однако я не знаю, как UUID создается и делается уникальным, или если он оказывается таким же, как по идентификатору устройства?

по метке тома также может хорошо работать, если вы или кто-то другой сделали хорошую метку тома для любой файловой системы, раздела или тома, которые должны быть смонтированы. Я уверен, что было бы проблематично, если бы два раздела имели одну и ту же метку тома, такую ​​как «загрузочный», например, я подозреваю, какую бы метку тома linux ни нашла первой, она использовала бы ее, если бы не сообщала о дублирующемся томе. этикетки.

Кроме того, все это основано на linux Udev (, чтобы ответить на вопрос, какой алгоритм используется ). Я считаю, что это то же самое, что и в старом Linux Init, и в новом Linux Systemd, поскольку Udev — это пакет, используемый в большинстве всех дистрибутивов Linux. Ия думаюэто в основном синтаксис в /etc/fstabв частности, первое поле или столбец в каждой строке определяет метод монтирования, который произойдет (не алгоритм ), что нет какого-то другой файл конфигурации где-то, и я говорю это, потому что у вас может быть несколько строк в /etc/fstab, каждая из которых монтирует что-то другое, используя другой метод монтирования (по имени, идентификатору, uuid или метке )и, насколько я знаю, больше ничего везде изменилось, кроме синтаксиса в файле fstab.