Стандарт на структуру каталогов файловой системы - Предисловие переводчика

Стандарт на структуру каталогов файловой системы - Предисловие переводчика Стандарт на структуру каталогов файловой системы (Filesystem Hierarchy Standard) Предисловие переводчика

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

И начать свои пояснения я хочу с рассуждения о выборе русского варианта названия стандарта. Дословный перевод названия ("Стандарт иерарахии файловой системы"), хотя он уже встречается в литературе (например, в книге Д.Бендела и Р.Нейпира "Использование Linux", М., "Вильямс", 2002 г.) кажется мне неудачным из-за того, что слово "иерархия" имеет в русском языке смысл, несколько отличающийся от смысла, вкладываемого в словосочетание "иерархическая структура". Возможно, в английском термин "Hierarchy" имеет много оттенков и точно выражает суть стандарта, а может быть он употреблен в названии только для краткости. Я не настолько хорошо владею английским, чтобы уверенно отстаивать какое-то из этих утверждений. Но для русского текста дословный перевод показался мне не адекватным содержанию, и я думаю, что для русскоязычного варианта имеет смысл подобрать сочетание терминов, более полно и точно выражающее его содержание.

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

Теперь еще о нескольких терминах.

Описание большинства каталогов в стандарте начинается с двух разделов, которые имеют в оригинале названия "Requirements" и "Specific Options". Первый термин переводится однозначно как "Требования", а второй термин можно перевести по разному.
Стандарт на структуру каталогов файловой системы. - Версия 2.2 финальная Версия для печати / Раздел "" () Стандарт на структуру каталогов файловой системы. (Filesystem Hierarchy Standard) Редакторы П.Рассел (Paul 'Rusty' Russell) и Д.Квинлан (Daniel Quinlan)

Filesystem Hierarchy Standard Group

Перевод на русский язык - В.А.Костромин, январь 2003 г. (Смотри ).
Оригинал перевода:

Abstract

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

Все торговые знаки и авторские права принадлежат их обладателям, если только специально не оговорено противное. Использование термина в этом документе не должно расцениваться как покушение на какой-либо торговый знак или фирменные знаки (Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark). математик сказал бы - на непересекающиеся подмножества): разделяемые файлы в противоположность неразделяемым и неизменяемые (статические) файлы как противоположность изменяемым файлам.

Разделяемые данные - это те, к которым может быть разрешен доступ с различных хостов; неразделяемые - те, которые являются специфическими для данного хоста. Например, домашние каталоги пользователей содержат разделяемые данные, а файлы блокирования устройств (device lock files) являются неразделяемыми.

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

Должно существовать простое и понятное соответствие между каталогами и типом данных, которые в этом каталоге размещаются: каталоги могут являться точками монтирования для других файловых систем, характеристики которых отличаются от характеристик той файловой системы, в которую они монтируются. Начало пояснений Различать разделяемые и неразделяемые файлы необходимо по следующим причинам:

При работе компьютера в сети (т.е.

В конце концов я выбрал вариант "Рекомендации", поскольку в этом разделе речь в большинстве случаев идет о тех подкаталогах рассматриваемого каталога, которые могут создаваться, а могут и не создаваться, в зависимости от того, устанавливаются ли соответствующие подсистемы. В общем-то речь всегда идет о требованиях создания определенных подкаталогов в текущем каталоге, но называть раздел "необязательные требования" как-то не по-русски. Так что пришлось назвать рекомендациями, хотя мне кажется, что это все-же требования, но по отношению к необязательным каталогам. Во многих разделах стандарта присутствуют пояснения, которые заключены между строками "Begin Rationale" и "End Rationale". Термин "Rationale" в англо-русском словаре переводится как "обоснования", но мне кажется более приемлемым именно "Пояснения", которое я и использую. И еще. Если я где-то не совсем верно перевел текст стандарта, это моя вина, не относите все ошибки на счет разработчиков стандарта. О любых замеченных вами ошибках прошу сообщать мне по адресу . В.А.Костромин, 9 января 2003 года.

в тех случаях, когда несколько компьютеров взаимосвязаны), всегда имеется достаточно значительная доля таких данных, которые могут использоваться совместно всеми компьютерами, что позволяет экономить дисковое пространство и облегчает выполнение задач поддержки и обслуживания (task of maintenance).
С другой стороны при работе в сети некоторые файлы содержат информацию, которая относится только к данному компьютеру. Следовательно, эти данные не могут использоваться другими хостами и не могут быть разделяемыми (если не принять специальных мер).
Старые реализации файловых систем для UNIX допускали размещение разделяемых и неразделяемых файлов в одних и тех же каталогах, ограничивая тем самым возможность делать разделяемыми по сети большие части файловой системы.

Выделение "разделяемых" данных может использоваться, например, для:

монтирования (в режиме "только для чтения") раздела /usr (или части /usr) по сети (используя NFS).
монтирования раздела /usr (или части раздела /usr) с носителя, допускающего только чтение. CD-ROM является одним из возможных примеров того, как одна копия файловой системы может использоваться другими FHS-совместимыми файловыми системами через "сеть" некоего рода.

Различие между "статическими" и "изменяемыми" данными оказывает влияние на структуру файловой системы по двум основным направлениям:

Поскольку корневой каталог / содержит как изменяемые, так и статические данные, он должен всегда монтироваться в режиме чтения-записи.
Поскольку традиционно каталог /usr содержал как статические, так и изменяемые данные, и поскольку мы теперь хотим монтировать его в режиме "только для чтения" (смотри выше), необходимо найти способ монтировать /usr только для чтения. Этого можно достичь, если создать каталоговую структуру /var, которая монтируется в режиме "чтение-запись" (либо размещается в другом разделе, где разрешены как чтение, так и запись, таком, как /), а в оставшейся части структуры /usr разрешить только чтение.

Приведем пример того, как должны распределяться данные для того, чтобы файловая система могла считаться совместимой со стандартом FHS (еще раз повторим, что это только пример, можно привести и другие примеры того, как размещать данные для обеспечения FHS-совместимости).

	Разделяемые	Неразделяемые
Статические	/usr	/etc
	/opt	/boot
Изменяемые	/var/mail	/var/run
	/var/spool/news	/var/lock

Таблица 2.1

Конец пояснений
, который поставляется в составе исходных кодов ядра. Он поддерживается Питером Анвином (H. Peter Anvin) <адрес пропущен>. Символические ссылки в каталоге /dev должны устанавливаться в Linux-системах не иначе как в соответствии с документом Linux Allocated Devices. НАЧАЛО ПОЯСНЕНИЙ
Требование не создавать символических ссылок произвольным образом выдвигается потому, что локальные установки часто отличаются от ссылок, создаваемых программами установки от разработчиков. Кроме того, если установочный скрипт дистрибутива создает символические ссылки во время инсталляции, эти ссылки часто не обновляются при локальных изменениях в аппаратном обеспечении. Если же ответственно относиться к ним на локальном уровне, они могут использоваться.
КОНЕЦ ПОЯСНЕНИЙ
/etc : Специфичная для данного хоста конфигурационная информация Если в Linux-системе следующие файлы требуются, они должны размещаться в /etc.

{ lilo.conf }

/proc : Виртуальные файловые системы для хранения информации о ядре и процессах Файловая система proc является фактически стандартным для Linux методом обработки информации о системе и процессах, в отличие от других систем, использующих /dev/kmem и другие подобные методы. Мы настоятельно рекомендуем использовать proc для хранения и получения информации о процессах, а также информации о ядре и памяти. /sbin : Основные системные утилиты В Linux-системах следующие дополнительные файлы размещаются в /sbin.

Команды для управления файловой системой ext2fs (Second extended filesystem) (optional):
- { badblocks, dumpe2fs, e2fsck, mke2fs, mklost+found, tune2fs }
Программа установки загрузчика системы (optional):
- { lilo }

Дополнительные файлы в /sbin:

Неизменяемые исполняемые файлы:
- { ldconfig, sln, ssync }
Статические исполняемые файлы ln (sln) и sync (ssync) используются в тех случаях, когда нормальный ход вещей нарушается. Основное назначение sln (восстанавливать некорректные символические ссылки в /lib после плохо организованного обновления) потеряло теперь былую важность, потому что имеется программа ldconfig (обычно расположенная в /usr/sbin), которая используется для обновления динамических библиотек.

Программа sync полезна в некоторых критических ситуациях. Заметим, что эти файлы не обязаны, но могут быть ссылками на стандартные программы ln и sync. Программа ldconfig не обязана размещаться в /sbin, поскольку сайт может использовать запуск ldconfig на этапе начальной загрузки, а не только во время обновления разделяемых библиотек. (Не ясно, имеются ли какие-то преимущества в запуске ldconfig при каждой загрузке системы.) Но даже если это так, некоторые люди любят использовать ldconfig в следующих (часто встречающихся) ситуациях:
1. Я только что удалил /lib/<file>.
2. Я не могу узнать (разыскать) имя библиотеки, потому что ls связано динамически (is dynamically linked), я использую оболочку, которая не имеет встроеной команды ls, а я не знаю, что вместо нее можно использовать "echo *".
3. У меня есть статическая ссылка sln, но я не знаю, что она вызывает.
Разное:
- { ctrlaltdel, kbdrate }
Чтобы найти выход из ситуации, когда некоторые клавиатуры поставляются с такой высокой скоростю повторения, что оказываются непригодны к использованию, kbdrate может быть в некоторых системах установлена в /sbin. Поскольку действием, которое ядро по умолчанию связывает с нажатием комбинации клавиш Ctrl-Alt-Del, является немедленная перезагрузка, обычно рекомендуется отменить отменить такое поведение перед монтированием корневой файловой системы в режиме только для чтения. Некоторые варианты демона init способны отменить действие Ctrl-Alt-Del, а другие требуют наличия программы ctrlaltdel, которая может быть установлена в таких системах в каталоге /sbin.

/usr/include : Файлы заголовков, включаемые в программы на C Эти символические ссылки требуются, если компиляторы языков C или C++ установлены и только для систем, не основанных на glibc. /usr/include/asm -> /usr/src/linux/include/asm-<arch> /usr/include/linux -> /usr/src/linux/include/linux /usr/src : Исходные коды Для систем, основанных на glibc, нет никаких специфических правил для этого каталога. Для систем, основанных на версиях библиотеки libc, предшествующих glibc, применяются следующие правила: Единственными исходными кодами, которые должны быть размещены в определенном месте, являются исходные коды ядра Linux.Они размещаются в /usr/src/linux. Если установлен компилятор C или C++, а полная версия исходных кодов ядра не установлена, то подключаемые файлы из исходных кодов ядра должны размещаться в следующих каталогах: /usr/src/linux/include/asm-<arch> /usr/src/linux/include/linux где <arch> - название архитектуры системы (например, i386). Замечание: /usr/src/linux может быть символической ссылкой на дерево каталогов с исходными кодами ядра. НАЧАЛО ПОЯСНЕНИЙ
Важно, чтобы подключаемые файлы ядра были расположены в /usr/src/linux, а не в /usr/include, так чтобы не было проблем, когда системные администраторы обновляют версию ядра в первый раз.
КОНЕЦ ПОЯСНЕНИЙ
/var/spool/cron : Задания для демонов cron и at Этот каталог содержит переменные данные для программ-демонов cron и at.