Иногда можно слышать о том, что архитектура Unix не имеет существенных недостатков. Особенно — если говорить о «чистой» архитектуре Research Unix (которая существовала до того, как те, кто по-настоящему Unix не понимали, вроде людей из Berkeley и AT&T, занялись работой над этой ОС). Но, к сожалению, на самом деле это не так. Решения, принятые создателями Research Unix относительно некоторых аспектов системы, не всегда, в исторической перспективе, удачные, всё ещё нас преследуют. Один из примеров этого — часть атрибутов файла, возвращаемых системным вызовом stat() и похожими вызовами, содержащая так называемый «номер устройства» («device number») файловой системы, в которой находится файл. Рассуждения о причинах того, почему всё устроено именно так, выходят за рамки данного материала, а вот о самом «номере устройства» мы поговорим.
(Если точнее, то речь идёт о поле
В Unix атрибуты файла пользовательского уровня, получаемые от
Правда, в ранних ОС Unix «номер устройства» был не неким абстрактным «идентификатором». Он представлял собой номер устройства для диска, с которого была смонтирована файловая система (отсюда и имя поля —
Теперь, спустя 40 долгих лет, у нас имеется множество файловых систем Unix, в основе которых нет блочных устройств (особенно это касается файловых систем, виртуальное адресное пространство которых представлено несколькими физическими носителями данных). Всё, что смонтировано с использованием одной из подобных файловых систем, должно как-то создавать для себя «номер устройства». При этом такой «номер» не может быть тем же самым, что и «номер» некоего реального блочного устройства. Это обычно требует от ОС семейства Unix выделять некую часть номеров блочных устройств, резервируя их для файловых систем, нуждающихся в подобных номерах, то есть — для файловых систем, не представленных блочными устройствами. К счастью, современные Unix-системы обычно используют пространства имён устройств, имеющие гораздо большую ёмкость, чем раньше.
(Далее, так как номера блочных устройств обычно стабильны и не подвержены изменениям, некоторые программы ожидают, что «номер устройства», возвращённый в составе атрибутов файла, тоже, в произвольно выбранной файловой системе, меняться не будет. Но когда ядру и файловой системе приходится генерировать подобные номера динамически — они далеко не всегда остаются неизменными).
Правда, в то же время, в V7 это, учитывая время и сопутствующие факторы, было хорошим архитектурным решением. Дело в том, что V7 создавалась как маленькая система. А в такой системе никто не стремится к выполнению неких действий в том случае, если в их выполнении нет абсолютной необходимости. Особенно это касается ядра. V7 может, практически без дополнительной нагрузки на систему, использовать в качестве идентификатора файловой системы номер устройства. Именно это и было сделано.
(В ядре V7 предпринимается целый ряд «обходных манёвров», направленных на упрощение реализации системы. Например, много всего хранится в маленьких массивах фиксированной длины. Причина этого в том, что, по мнению разработчиков системы, ей никогда не понадобится хранить очень длинные списки процессов, открытых файлов и прочего подобного.)
Сталкивались ли вы со странностями Unix, которые можно объяснить архитектурными решениями, принятыми много лет назад?
(Если точнее, то речь идёт о поле
st_dev структуры stat, возвращаемой stat(). Это поле присутствовало там со времён существования stat.h из V7. Авторы stat() из V6 ещё более внимательно относились к тому, что должен возвращать этот вызов.)В Unix атрибуты файла пользовательского уровня, получаемые от
stat(), должны включать в себя некий локально уникальный идентификатор для файловой системы, в которой находится файл. Поэтому присутствие в составе атрибутов некоего идентификатора — это не ошибка. Наличие у двух файлов разных идентификаторов позволяет выяснять различные подробности об этих файлах. Например — сведения о том, что мы находимся в точке монтирования файловой системы, о том, что нельзя использовать link(), или о том, что два файла, выглядящих абсолютно одинаковыми, на самом деле, не связаны друг с другом жёсткой ссылкой, так как находятся в разных файловых системах. Кроме того, полезным может оказаться иметь идентификатор, который можно с чем-то сопоставлять, например — со списком смонтированных файловых систем.Правда, в ранних ОС Unix «номер устройства» был не неким абстрактным «идентификатором». Он представлял собой номер устройства для диска, с которого была смонтирована файловая система (отсюда и имя поля —
st_dev). И именно с этой целью он и создавался. Печальным последствием этого решения явился тот факт, что два логически несвязанных пространства имён идентификаторов оказались навсегда связаны друг с другом. Речь идёт о пространстве имён (смонтированных) файловых систем и о пространстве имён блочных устройств.Теперь, спустя 40 долгих лет, у нас имеется множество файловых систем Unix, в основе которых нет блочных устройств (особенно это касается файловых систем, виртуальное адресное пространство которых представлено несколькими физическими носителями данных). Всё, что смонтировано с использованием одной из подобных файловых систем, должно как-то создавать для себя «номер устройства». При этом такой «номер» не может быть тем же самым, что и «номер» некоего реального блочного устройства. Это обычно требует от ОС семейства Unix выделять некую часть номеров блочных устройств, резервируя их для файловых систем, нуждающихся в подобных номерах, то есть — для файловых систем, не представленных блочными устройствами. К счастью, современные Unix-системы обычно используют пространства имён устройств, имеющие гораздо большую ёмкость, чем раньше.
(Далее, так как номера блочных устройств обычно стабильны и не подвержены изменениям, некоторые программы ожидают, что «номер устройства», возвращённый в составе атрибутов файла, тоже, в произвольно выбранной файловой системе, меняться не будет. Но когда ядру и файловой системе приходится генерировать подобные номера динамически — они далеко не всегда остаются неизменными).
Правда, в то же время, в V7 это, учитывая время и сопутствующие факторы, было хорошим архитектурным решением. Дело в том, что V7 создавалась как маленькая система. А в такой системе никто не стремится к выполнению неких действий в том случае, если в их выполнении нет абсолютной необходимости. Особенно это касается ядра. V7 может, практически без дополнительной нагрузки на систему, использовать в качестве идентификатора файловой системы номер устройства. Именно это и было сделано.
(В ядре V7 предпринимается целый ряд «обходных манёвров», направленных на упрощение реализации системы. Например, много всего хранится в маленьких массивах фиксированной длины. Причина этого в том, что, по мнению разработчиков системы, ей никогда не понадобится хранить очень длинные списки процессов, открытых файлов и прочего подобного.)
Сталкивались ли вы со странностями Unix, которые можно объяснить архитектурными решениями, принятыми много лет назад?
