Жёсткая ссылка на каталог и системные ограничения

Где конкретнее почитать про эти system restrictions
зачем они включены по умолчанию?

https://unix.stackexchange.com/questions/22394/why-hard-links-not-allowed-to-...

TL;DR версия для Ъ:

Allowing hard links to directories would break the directed acyclic graph structure of the filesystem, possibly creating directory loops and dangling directory subtrees, which would make fsck and any other file tree walkers error prone.

как их отключить

Пропатчив драйвер ФС или даже всю VFS, точнее не скажу - надо копаться в сырцах ядра

Спасибо за ссылку.

possibly creating directory loops

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

Ведь даже rm для корня не запрещён

Однако опцию --no-preserve-root ввели. Здесь же проблема глубже - прикладное ПО может натурально охренеть от таких вот раскладов(например find, в котором, ЕМНИП писали какие-то обертки для симлинков вида 'boot -> .' и прочего)

mount --bind, регистрирующий подобное как точку монтирования в этом плане более кошерен

Вдобавок, если спуститься на уровень ФС, то получается что директория - это всего-лишь «файл»(грубо), к которому привязаны другие файлы

Что ты хочешь реализоваться хардлинком(а не симлинком) директории? Костыльный бэкап?

Это качественно разные способы прострелить себе ногу. Если ты сделаешь rm -rf /, то результат будет детерминированным: ты потеряешь все данные на корневом разделе.

А если применить к произвольному графу алгоритм, который предназначен для DAG, то можно получить треш и угар произвольной степени печальности. Ты можешь сделать rm директории, поддерево которой на неё ссылается, и тупо потерять место: возникнет кусок иерархии, к которому не будет пути из корня (т. е. граф перестанет быть связным). А алгоритм обхода в fsck, встретив что-то подобное, просто уйдёт в бесконечную рекурсию. И так далее.

Однако опцию --no-preserve-root ввели

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

Здесь же проблема глубже - прикладное ПО может натурально охренеть от таких вот раскладов

Да, с этим могут быть проблемы. С другой стороны, у меня когда-то убунта с второгномом не могла нормально работать с ярлыками (*.desktop) на рабочем столе при noexec на /home, т.е. здесь это похоже на баг прикладного ПО при использовании штатных инструментов ОС.

Вдобавок, если спуститься на уровень ФС, то получается что директория - это всего-лишь «файл»(грубо), к которому привязаны другие файлы

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

Что ты хочешь реализоваться хардлинком(а не симлинком) директории? Костыльный бэкап?

Нет, я интересуюсь чисто из теоретически-познавательных целей. Ведь если существует такая опция — значит где-то это реализовано и используется (или кода-то использовалось).

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

В данном случае нет почти никакой разницы с симлинком. Почему почти - смотри ниже.

Ведь если существует такая опция — значит где-то это реализовано и используется (или кода-то использовалось).

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

А геморроя с поддержкой - больше. Ну и напуркуа это надо? :-)

Ну и напуркуа это надо?

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

А алгоритм обхода в fsck, встретив что-то подобное, просто уйдёт в бесконечную рекурсию.

Скорее, он «починит» это повреждение. Fsck изначально проектируются для работы на повреждённых образах ФС, и цикл в дереве директорий — просто один из обрабатываемых вариантов.

хардлинк на директорию это тоже самое что и симлинк, но его можно сделать только в пределах одного раздела на жестком диске

Это если есть достаточные права во всём дереве на пути к каталогу, на который ссылается символическая ссылка, иначе permission denied.

А геморроя с поддержкой - больше. Ну и напуркуа это надо? :-)

Тогда возникает другой вопрос: если корректной поддержки нет — для чего существует сабжевая опция в ln?

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

попробуй рекурсивно удалить каталог, внутри которого находится хардлинк на него самого.

Тогда возникает другой вопрос: если корректной поддержки нет — для чего существует сабжевая опция в ln?

для того, что ln - это часть GNU fileutils, которая может быть запущена на ядре, отличном от linux, в котором разрешены хардлинки на директории.

И почему это нельзя сделать, например, с помощью zfs-клонов? В Btrfs тоже что-то подобное есть ЕМНИП.

Тогда возникает другой вопрос: если корректной поддержки нет — для чего существует сабжевая опция в ln?

Для поддержки в не-Linux системах? Или ты думал, что другими клонами UNIX никто уже не пользуется? :-)

попробуй рекурсивно удалить каталог, внутри которого находится хардлинк на него самого.

Много раз такое делал =)
Ибо внутри любого каталога есть хардлинк на него самого - ".".

А что, обязательно на "боевой машине" использовать вместо файловой системы непонятное говно?

В reiserfs этого нет. В жалком подобии — ext3 — тоже нет. А больше стабильных и приличных ФС не существует!

Time Machine их использует

ну ты нормальный хардлинк возьми, а не этот специальный файл, с которым ты не можешь сделать ничего.

попробуй рекурсивно удалить каталог

Если бы мог — попробовал бы.

внутри которого находится хардлинк на него самого

А ещё можно яйца дверью прищемить.

Если бы мог — попробовал бы.

а ты в уме себе представь

А ещё можно яйца дверью прищемить.

ну так это одна из тех проблем, про которые тебе тут говорят.

Для поддержки в не-Linux системах?

Да, но там же свои утилиты есть. Например, в BSD-шном и в яблочном directories may not be hardlinked. Впрочем, переносимость это хорошо.

может быть запущена на ядре, отличном от linux, в котором разрешены хардлинки на директории

Интересно, а как на таких ядрах решается проблема с рекурсивными хардлинками: всё ломается, присутствует защита от дурака или есть какие-то особенности в реализации вызовов ядра или ФС, позволяющие корректно обрабатывать такие ситуации?

ext3

А почему не ext4?

Потому что ext4 — дрянь?

В reiserfs этого нет. В жалком подобии — ext3 — тоже нет.

В порядке оффтопа:

У меня для тебя плохие новости - эти ФС устарели. Нет, серьезно, мне очень нравится reiserfs(потому что по сравнению с ext3 - она реально няшная), но когда 750 гиговый раздел штатно монтируется около двух минут при загрузке - это повод задуматься о том, что что-то не так.

Btrfs и ZFS - это те ФС, за возможностями которых - будущее. Да, их возможности не сильно подходят к HDD, они лучше раскрывают себя на SSD, но, опять же - механика в жестких дисках отживает своё, ИМХО.

Да, но там же свои утилиты есть.

А кто тебе сказал, что нельзя использовать другой userland на данных системах?

как на таких ядрах решается проблема с рекурсивными хардлинками: всё ломается, присутствует защита от дурака или есть какие-то особенности в реализации вызовов ядра или ФС, позволяющие корректно обрабатывать такие ситуации?

по хорошему должен быть третий вариант, а как на самом деле - хз

механика в жестких дисках отживает своё

Ты думаешь, в ближайшие пару лет появятся SSD емкостью 4..10ТБ по цене 1500р за терабайт?

Потому что ext4 — дрянь?

В сравнении с тормозной ext3, которая могла часами проверяться на разделах в сотни гигабайт, ext4 — как глоток свежего воздуха.

А кто тебе сказал, что нельзя использовать другой userland на данных системах?

А я и не говорил что нельзя, просто не вижу смысла делать лишние телодвижения если изкоробки всё работает.

750 гиговый раздел штатно монтируется около двух минут при загрузке

У меня терабайтный диск с ext4 монтируется за секунду. IMHO твой диск начал сыпаться.

Btrfs и ZFS - это те ФС, за возможностями которых - будущее.

Иногда нужна просто ФС, а не комбайн с крылом изменяемой стреловидности.

в ближайшие пару лет

Нет. В ближайшие пару десятков лет - да

У меня терабайтный диск с ext4 монтируется за секунду. IMHO твой диск начал сыпаться.

Показатели smart в норме, диск читается. А ты не внимательно прочитал - 750 гиговый раздел с reiserfs. После бэкапа и форматирования в ext4 всё нормально.

Проблема именно в reiserfs - я воспроизвел на других жестких дисках - разделы больше 500 гигабайт для неё - большеваты.

Причем скорость работы с данными - нормальная, проблема только в монтировании.

Иногда нужна просто ФС, а не комбайн с крылом изменяемой стреловидности.

ext4 - как раз такая ФС. Еще в некоторых случаях xfs себя вполне оправдывает. Я не пропагандирую применять btrfs и zfs повсеместно. Особенно учитывая расход памяти на некоторые фичи той же zfs. Но для файловых серверов zfs действительно очень даже неплоха.

В ближайшие пару десятков лет

Ну, это еще когда... А нужно здесь и сейчас!

А через пару десятков лет глядишь, новые технологии изобретут. И будут люди в кармане таскать флешки на десяток ТБ!

А ты не внимательно прочитал - 750 гиговый раздел с reiserfs. После бэкапа и форматирования в ext4 всё нормально.

Что-то странно у тебя. Я никогда не замечал, чтобы монтирование было долго. Даже двухтерабайтные разделы быстро монтируются.

Вот fsck — да, долго. Но где оно быстро? Только на SSD, за счет скорости самой SSD.

А уж если fsck на двухтерабайтном разделе с ext3 выполнять... У, до третьего пришествия ждать будешь!

А уж если fsck на двухтерабайтном разделе с ext3 выполнять... У, до третьего пришествия ждать будешь!

Если уж оффтопить, так оффтопить. Недавно на #gentoo-dev один чувак рассказывал, что у него есть старый сервак, который нельзя особо трогать - рассыплется :-). С него уже и все службы поснимали, но еще не закопали - крутится там какая-то никому не нужная приблуда. Вот там есть раздел примонтированный по iSCSI с reiserfs. Раздел как раздел - 9 Tb размером. И вот сервак неожиданно ребутнулся - то ли питание пропало, то ли kernel panic, я в подробности не вдавался - читал уже backlog, а не присутствовал в процессе беседы.

И надо ж такому было случиться, что обычный fsck соснул и надо было применять reiserfsck --rebuild-tree(знатоки reiserfs тут уже напряглись, я их понимаю)...

Короче fsck шел 4 дня :-)

reiserfsck --rebuild-tree
4 дня

Дык, на ext3 оно бы 4 года шло =D

А с ext4 не знаю. Не хочу проверенную reiserfs на коня в пальто менять.

Потому что ext4 — дрянь

А с ext4 не знаю

Эдуард, ну нельзя же так сразу.

Все, что не пробовал — дрянь =D

Кстати, почему дедупликацию и сжатие стремятся засунуть именно внутрь ФС? Здесь напрашивается реализация в стиле encfs/ecryptfs, чтобы это могло работать поверх той же ext4, заодно можно будет включить не на весь раздел.

reiserfsck --rebuild-tree

знатоки reiserfs тут уже напряглись, я их понимаю

:]