Открыть список
Как стать автором
Обновить
2714,2
Рейтинг
RUVDS.com
VDS/VPS-хостинг. Скидка 10% по коду HABR

Заметки о Unix: изъян архитектуры Unix и номер устройства, который выдаёт для файлов системный вызов stat()

Блог компании RUVDS.comНастройка LinuxСистемное администрирование*nix
Перевод
Автор оригинала: Chris Siebenmann
Иногда можно слышать о том, что архитектура Unix не имеет существенных недостатков. Особенно — если говорить о «чистой» архитектуре Research Unix (которая существовала до того, как те, кто по-настоящему Unix не понимали, вроде людей из Berkeley и AT&T, занялись работой над этой ОС). Но, к сожалению, на самом деле это не так. Решения, принятые создателями Research Unix относительно некоторых аспектов системы, не всегда, в исторической перспективе, удачные, всё ещё нас преследуют. Один из примеров этого — часть атрибутов файла, возвращаемых системным вызовом stat() и похожими вызовами, содержащая так называемый «номер устройства» («device number») файловой системы, в которой находится файл. Рассуждения о причинах того, почему всё устроено именно так, выходят за рамки данного материала, а вот о самом «номере устройства» мы поговорим.



(Если точнее, то речь идёт о поле st_dev структуры stat, возвращаемой stat(). Это поле присутствовало там со времён существования stat.h из V7. Авторы stat() из V6 ещё более внимательно относились к тому, что должен возвращать этот вызов.)

В Unix атрибуты файла пользовательского уровня, получаемые от stat(), должны включать в себя некий локально уникальный идентификатор для файловой системы, в которой находится файл. Поэтому присутствие в составе атрибутов некоего идентификатора — это не ошибка. Наличие у двух файлов разных идентификаторов позволяет выяснять различные подробности об этих файлах. Например — сведения о том, что мы находимся в точке монтирования файловой системы, о том, что нельзя использовать link(), или о том, что два файла, выглядящих абсолютно одинаковыми, на самом деле, не связаны друг с другом жёсткой ссылкой, так как находятся в разных файловых системах. Кроме того, полезным может оказаться иметь идентификатор, который можно с чем-то сопоставлять, например — со списком смонтированных файловых систем.

Правда, в ранних ОС Unix «номер устройства» был не неким абстрактным «идентификатором». Он представлял собой номер устройства для диска, с которого была смонтирована файловая система (отсюда и имя поля — st_dev). И именно с этой целью он и создавался. Печальным последствием этого решения явился тот факт, что два логически несвязанных пространства имён идентификаторов оказались навсегда связаны друг с другом. Речь идёт о пространстве имён (смонтированных) файловых систем и о пространстве имён блочных устройств.

Теперь, спустя 40 долгих лет, у нас имеется множество файловых систем Unix, в основе которых нет блочных устройств (особенно это касается файловых систем, виртуальное адресное пространство которых представлено несколькими физическими носителями данных). Всё, что смонтировано с использованием одной из подобных файловых систем, должно как-то создавать для себя «номер устройства». При этом такой «номер» не может быть тем же самым, что и «номер» некоего реального блочного устройства. Это обычно требует от ОС семейства Unix выделять некую часть номеров блочных устройств, резервируя их для файловых систем, нуждающихся в подобных номерах, то есть — для файловых систем, не представленных блочными устройствами. К счастью, современные Unix-системы обычно используют пространства имён устройств, имеющие гораздо большую ёмкость, чем раньше.

(Далее, так как номера блочных устройств обычно стабильны и не подвержены изменениям, некоторые программы ожидают, что «номер устройства», возвращённый в составе атрибутов файла, тоже, в произвольно выбранной файловой системе, меняться не будет. Но когда ядру и файловой системе приходится генерировать подобные номера динамически — они далеко не всегда остаются неизменными).

Правда, в то же время, в V7 это, учитывая время и сопутствующие факторы, было хорошим архитектурным решением. Дело в том, что V7 создавалась как маленькая система. А в такой системе никто не стремится к выполнению неких действий в том случае, если в их выполнении нет абсолютной необходимости. Особенно это касается ядра. V7 может, практически без дополнительной нагрузки на систему, использовать в качестве идентификатора файловой системы номер устройства. Именно это и было сделано.

(В ядре V7 предпринимается целый ряд «обходных манёвров», направленных на упрощение реализации системы. Например, много всего хранится в маленьких массивах фиксированной длины. Причина этого в том, что, по мнению разработчиков системы, ей никогда не понадобится хранить очень длинные списки процессов, открытых файлов и прочего подобного.)

Сталкивались ли вы со странностями Unix, которые можно объяснить архитектурными решениями, принятыми много лет назад?

Теги:Unixсистемное администрирование
Хабы: Блог компании RUVDS.com Настройка Linux Системное администрирование *nix
Всего голосов 38: ↑34 и ↓4 +30
Просмотры6.5K

Комментарии 3

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Похожие публикации

Лучшие публикации за сутки

Информация

Дата основания
Местоположение
Россия
Сайт
ruvds.com
Численность
11–30 человек
Дата регистрации
Представитель
ruvds

Блог на Хабре