Почему жесткая ссылка в Unix?

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

Я говорю от болезненного личного опыта здесь.

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

Но существует оборотная сторона: Firefox является большим. Действительно большой. Это было видом версии 1.x проекта, таким образом, они не нашли время для вещей как удаление поддержки GUI. [*] Моему сайту не было нужно ни одно из этого, но потому что технология VPS, которую мой используемый поставщик услуг хостинга не позволил области подкачки, которую код GUI и все другие части Firefox я не использовал, съела реальную RAM. Я закончил тем, что нуждался в минимуме RAM на 512 МБ только для выполнения сайта без него отказывающий из-за исчерпания памяти. Если мой VPS имел некоторую область подкачки, я, вероятно, возможно, обошелся планом на 256 МБ.

[*] Удаление кода GUI от платформы даже не могло быть желательным, так как одно из преимуществ этой платформы было высокочастотной веб-очисткой, потому что серверная платформа могла загрузить веб-страницы с другого сайта, и Вы могли управлять ими так же, как Вы будете на стороне клиента. Думайте мэшапы. Много такой вещи повредилось бы, если Вы не можете "представить" веб-страницу в некотором графическом контексте.

Между прочим, эта веб-платформа чрезвычайно мертва теперь, таким образом, нет никакого смысла называть-и-позорить она. Лучше всего просто принимать более широкий урок близко к сердцу: да, подкачка все еще полезна, даже если у Вас есть концерты свободной RAM.

51
15.10.2011, 20:09
2 ответа

Интересный вопрос, действительно. На первый взгляд я вижу следующие преимущества:

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

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

Когда файл создается или удаляется из каталога, штамп времени изменения каталога должен быть обновлен, также. Эта метка времени хранится в ее inode. inode число хранится в соответствующей записи каталога.

ЕСЛИ БЫ точечная запись не была бы там, стандартные программы должны были бы искать inode число при записи для этого каталога в родительском каталоге, который вызовет поиск каталога снова.

НО к счастью в текущем каталоге существует точечная запись. Стандартная программа, которая добавляет или удаляет файл в текущем каталоге просто, должна перейти назад к первой записи (где точечная запись обычно находится), и сразу нашел inode число для текущего каталога.

Существует третья хорошая вещь о точечной записи:

Когда fsck проверяет гнилую файловую систему и должен иметь дело с несвязанными блоками, которые находятся также не в бесплатном списке, для него легко проверить, имеет ли блок данных (при интерпретации как список каталога) точечную запись, это указывает на inode, который в свою очередь указывает назад на этот блок данных. Если так, этот блок данных можно рассмотреть как потерянный каталог, который должен быть повторно подключен.

37
27.01.2020, 19:33
  • 1
    Очень полезный ответ. –  Navaneeth K N 21.10.2011, 14:58
  • 2
    Комментарий о стандартных программах, ищущих каталог inode, является поддельным. Стандартные программы ядра не имеют никакой потребности искать . в текущем каталоге. Если Вы не можете найти ядро, где оно на самом деле прокладывает себе путь (я сомневаюсь относительно этого...) –  Dietrich Epp 30.11.2012, 02:32
  • 3
    я соглашаюсь с @DietrichEpp; чтобы система посмотрела на записи каталога во-первых, она должна уже знать о inode - потому что это - то, как это добирается до блоков данных, содержащих записи каталога. –  Lqueryvg 21.11.2014, 15:13

(Хм: следующее является теперь чем-то вроде эпопеи...),

Дизайн каталога в файловых системах Unix (который, чтобы быть педантичным, обычно, но не обязательно присоединен к OSs Unix) представляет замечательное понимание, которое на самом деле сокращает количество требуемых особых случаев.

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

Единственный специальный inode является inode номером 2 (не 0 или 1 по причинам Традиции); inode 2 является файлом каталога: корневой каталог. Когда система монтирует файловую систему, она 'знает', что имеет к readdir inode 2, для запущения себя.

Файл каталога является просто файлом с внутренней структурой, которая предназначается, чтобы быть считанной opendir (3) и друзья. Вы видите его внутреннюю структуру, зарегистрированную в dir (5) (в зависимости от Вашей ОС); при рассмотрении этого Вы будете видеть, что запись файла каталога не содержит почти информации о файле - это - все в файле inode. Одна из нескольких вещей, это является особенным об этом файле, - то, что открытое (2) функция будет, учитывая ошибку, при попытке открыть файл каталога с режимом, который разрешает писать. Различные другие команды (для выбора всего одного примера, hexdump) откажется действовать нормальным способом с файлами каталога, просто потому что это, вероятно, не, что Вы хотите сделать (но это - их особый случай, не файловая система).

Жесткая ссылка - ничто больше, ни меньше, чем запись в карте файла каталога. Вы можете иметь два (или больше) записи в такой карте который обе карты к тому же inode числу: это inode поэтому имеет два (или больше) жесткие ссылки. Это также объясняет, почему каждый файл имеет по крайней мере одну 'жесткую ссылку'. inode имеет подсчет ссылок, который записывает, сколько раз это inode упоминается в файле каталога где-нибудь в файловой системе (это - число, которое Вы видите, когда Вы делаете ls -l).

Хорошо: мы переходим к сути дела теперь.

Файл каталога является картой строк ('имена файлов') к числам (inode числа). Те inode числа являются числами inodes файлов, которые находятся 'в' том каталоге. Файлы, которые находятся 'в' том каталоге, могли бы включать другие файлы каталога, таким образом, их inode числа будут среди перечисленных в каталоге. Таким образом, если у Вас есть файл /tmp/foo/bar, затем файл каталога foo включает запись для bar, отображение той строки к inode для того файла. В файле каталога существует также запись /tmp, для файла каталога foo который находится 'в' каталоге /tmp.

Когда Вы создаете каталог с mkdir (2), та функция

  1. создает файл каталога (с некоторым inode числом) с корректной внутренней структурой,
  2. добавляет запись в родительский каталог, отображая название нового каталога к этому новому inode (который составляет одну из ссылок),
  3. добавляет запись в новый каталог, отображая строку '.' на тот же inode (это составляет другую ссылку), и
  4. добавляет другая запись в новый каталог, отображая строку '..' к inode файла каталога это изменило на шаге (2) (это составляет большее число жестких ссылок, на которых Вы будете видеть на файлах каталога, которые содержат подкаталоги).

Конечный результат состоит в том, что (почти) единственные особые случаи:

  • Открытое (2) функция пытается мешать стрелять себе в ногу путем предотвращения Вас вводные файлы каталога для записи.
  • mkdir (2) функция делает вещи хорошими и легкими путем добавления нескольких дополнительных записей (''. и '..') в новый файл каталога, просто для создания удобным переместить файловую систему. Я подозреваю, что файловая система работала бы отлично без'.' и '..', но была бы боль для использования.
  • Файл каталога является одним из нескольких типов файлов, которые отмечаются как 'особенные' - это действительно, что говорит, что вещам нравится, открывают (2) для поведения немного по-другому. Посмотрите st_mode в статистике (2).

(скопированный с stackoverflow исходного вопроса, 20.10.2011)

10
27.01.2020, 19:33
  • 1
    Вы путаете блоки с inodes. Как особый случай, для коротких файлов, содержание файла могло бы быть в inode, но это обманывает, утверждают, что inodes не структурированы. Они высоко структурированы, содержа почти все метаданные файла кроме имен файлов, которыми мог бы быть найден файл. inode содержит указатели (прямой, косвенный, вдвойне косвенный, и т.д.) к блокам на диске, где содержание файла. –  Phil P 10.03.2012, 04:00
  • 2
    Нет, я не путаю блоки с inodes. inodes являются абстракцией, находящейся выше блоков, и точка этой регистрации должна была описать отношения между файлами и каталогами и их содержанием: вся структура файловой системы прибывает из файлов каталога. Это уже было достаточно длинно, не увязая в inode реализациях! (который сказал, я мог возможно записать эти первые два абзаца более ясно). Кроме того, как Вы видите, я действительно явно заявляю, что вся информация о файле (кроме его имени) находится в inode, а не в файле каталога. –  Norman Gray 05.04.2012, 14:32
  • 3
    @NormanGray: Как раз когда Вы защищаете себя, Вы стреляете себе в ногу.   Вы сказали, "Все фактическое содержание файлов в файловой системе находится в inodes....",  Это неправильно.   Свойства / атрибуты файла (например, владелец, полномочия, время изменения, и т.д.) хранятся в inode.   содержание обычного файла хранится в блоках данных.  , Если Вы не хотите увязать в inode реализациях, затем не делайте, но не делайте вводящие в заблуждение упрощения, также. –  G-Man Says 'Reinstate Monica' 29.06.2015, 07:35

Теги

Похожие вопросы