[Настройка Linux, Системное администрирование, *nix] Заметки о Unix: изъян архитектуры Unix и номер устройства, который выдаёт для файлов системный вызов stat() (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Иногда можно слышать о том, что архитектура 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, которые можно объяснить архитектурными решениями, принятыми много лет назад?
оригинал
===========
Источник:
habr.com
===========
===========
Автор оригинала: Chris Siebenmann
===========Похожие новости:
- [Системное администрирование, Программирование, IT-инфраструктура, Apache] Как Apache Kafka поддерживает 200К партиций в кластере? (перевод)
- [Системное администрирование, Софт, IT-компании] В Windows 10 Insider Preview Build 21322 Microsoft закрыла возможность вызвать баг для повреждения файловой системы NTFS
- [Системное администрирование, *nix, DevOps, Микросервисы, Kubernetes] Ломаем и чиним etcd-кластер
- [Open source, *nix] FOSS News №58 – дайджест материалов о свободном и открытом ПО за 22-28 февраля 2021 года
- [Мессенджеры, Open source, Системное администрирование, PHP, Программирование] Введение в метрики для PHP разработчика
- [Big Data, Математика, Карьера в IT-индустрии] За что IT-компании платят экономистам и сколько стоит человеческая жизнь?
- [Системное администрирование, Python] Как ленивый работящему помог. Ещё один скрипт для релиза подкаста
- [Системное администрирование, Разработка под Windows, Софт] Почему Windows около 20 секунд упорядочивает невидимые значки Рабочего стола? (перевод)
- [Системное администрирование, Серверное администрирование] Рамка (граница) окон в windows 10 и server 2016+
- [Системное администрирование, IT-инфраструктура, DevOps] Что вам нужно знать, если вы поменяете nginx на envoy: впечатления спустя два года
Теги для поиска: #_nastrojka_linux (Настройка Linux), #_sistemnoe_administrirovanie (Системное администрирование), #_*nix, #_unix, #_sistemnoe_administrirovanie (системное администрирование), #_blog_kompanii_ruvds.com (
Блог компании RUVDS.com
), #_nastrojka_linux (
Настройка Linux
), #_sistemnoe_administrirovanie (
Системное администрирование
), #_*nix
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 12:59
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Иногда можно слышать о том, что архитектура 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, которые можно объяснить архитектурными решениями, принятыми много лет назад?  оригинал =========== Источник: habr.com =========== =========== Автор оригинала: Chris Siebenmann ===========Похожие новости:
Блог компании RUVDS.com ), #_nastrojka_linux ( Настройка Linux ), #_sistemnoe_administrirovanie ( Системное администрирование ), #_*nix |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 12:59
Часовой пояс: UTC + 5