Архитектура файловых систем Linux (Быть или не быть циклическим ссылкам)

[codec]

Всем привет.
Я не так давно в Линуксе, и на данный момент меня мучает вопрос: а оптимально ли использование в Linux так называемых Symbolic Links? (в принципе и Hard Links наверное, если они могут ссылаться на каталоги, которые в на физическом уровне тоже представляют из себя файлы).
С одной стороны бонус в виде того, что не надо делать физические копии один и тех же файлов.
С другой стороны недостаток в виде потери древовидной структуры файловой системы, и превращения ее в неупорядоченный граф.

Как в случае такого графа работает поиск по диску? Ведь он должен как то отслеживать, что текущие ребро графа диска он еще не проходил?

[codec]

На мой взгляд решение очень сомнительное. Может я чего не понимаю и смысл не только в одном сэкономленоом месте? Но после прочтения стандарта FHS я для себя ничего другого не вынес.
А вот проблемы в связи с линками возникают на мой взгляд серъезные.
- Усложнение ядра
- Потеря упорядоченной структуры дерева.

Кто нибудь кинет ссылочку на ньюс группы разработчиков, где это можно обсудить?

[snake]

А вот проблемы в связи с линками возникают на мой взгляд серъезные.
- Усложнение ядра

↑

Вам так жалко бедное ядро ниасиливающее непомерной работы по учету линков?

Как в случае такого графа работает поиск по диску?

↑

Легко работает. См. man find за разъяснениями.

в принципе и Hard Links наверное, если они могут ссылаться на каталоги

↑

Теоретически, жеские ссылки на каталоги возможны, но делать их может только рут и, вообеще, такое занятие считается крайне нездоровым.

а оптимально ли использование в Linux так называемых Symbolic Links?

↑

Все хорошо в меру. В любом случае линки предают дополнительную гибкость в управлении системой, а это никогда не лишне, если, конечно, не перегибать.

Стоит ли напоминать, что отдаленным и несовсем полноценным, но все-таки аналогом симлинков являются ярлыки в виндос. И то, что они там эволюционируют уже лет 15, о чем-то то говорит, ведь так!? Кстати, интересный факт: ntfs поддерживает хардлинки. (правда, виндовс не имеет штатных средств к созданию оных )

Кто нибудь кинет ссылочку на ньюс группы разработчиков, где это можно обсудить?

↑

А чего тут обсуждать то? Им уже лет 25 и все споры похоронены под такой глубиной культурного слоя, что представляют интерес чисто археологический. Тем более их все равно не отменишь, даже если очень сильно захотеть: слишком много стандартных вещей замешано на симлинках, хотя бы тот же SysV init
История уже все рассудила: Линкам быть!

[codec]

man find

Действительно помогло. Спасибо.

-P Never follow symbolic links. This is the default behaviour.

В случае с софт линками ясно теперь. Они действительно не нарушают древовидную структуру файловой системы.
Сравнение с ярлыками помоему удачное. Почему я сразу не провел паралели, так это наверное потому что ярлыки в виндовс не есть часть функциональности ни файловой системы ни ядра. Это просто файлы специального содержания, которые обрабатываются оболочкой - эксплорером.

А вот хард линки на папки - действительно нарушают. Потому как распознать циклический линк на их основе я думаю действительно сложно. И понятно почему они попали в немилость ;-) Надеюсь в скором времени это будет действительно не вопрос, и эту функциональность вообще заблокируют.

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

Хм. Похоже у меня больше нет вопросов. Все выяснилось достаточно легко.

[diesel]

codec, Вас не смущает что в _любой_ обычной папке находится по крайней мере два хардлинка на папки ... и пользуются ими очень часто

[codec]

diesel
Согласно спецификации файловой системы. Каждый каталог имеет две специальные ссылки '..' и '.'. Во всех каталогах (кроме /) .. - ссылается на родительский каталог, а . - на самого себя. В корневом каталоге .. - тоже ссылается на себя.
Не смущает потому что это _специализированные_ ссылки, необходимые для поддержания структуры FS.
И я надеюсь что существующая инфраструктура не позволяет менять описанное поведение ссылок.

[polachok]

быть или не быть циклическим ссылкам

ln -s a b
ln -s b a
cat a
cat: a: Слишком много уровней символьных ссылок

[diesel]

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

это самые обыкновенные жесткие ссылки на директории ...

[codec]

Нинада ничего блокировать!!!

↑

В данном случае речь идет о потенциально опасной функциональности. И блокирование таких вещей - как движение в сторону улучшения архитектуры.
Вы ведь не будете говорить "Давайте оставим" различного рода дыры, недоработки?
Если в данном случае коммунити признало нард линки на папки "злом", то разумно в будущем, оставив делту по времени для программного обеспечения которое возможно это функциональность использует, избавляться от этого.
Это на самом деле тонкий вопрос - найти золотую середину между исторически сформировавшимися вещами и актуальными улучшениями.
В том же стандарте FHS встречается не раз записи вроде "mtab does not fit the static nature of /etc: it is excepted for historical reasons".

ln -s a b
ln -s b a
cat a
cat: a: Слишком много уровней символьных ссылок

Это как я понимаю пример "как ни надо делать" =) Будемс знать.

[snake]

Хард линки на папки просто так может создать только рут. Деструктивного в этом не больше, чем в сакраментальном rm -Rf /. По здравому размышлению, даже меньше. Рут сказал "надо" значит действительно надо, на то он и рут --- знает, что делает.

А если не знает, то тут никакие подстеленные саломки не спасут --- проблема некомпетенции техническими средствами не решается.

И еще не принято в *nix ради отдельных частных случаев нарушать общие принципы.

[aLexx programmer]

В данном случае речь идет о потенциально опасной функциональности.

↑

Почти любая функциональность с какой-то стороны "потенциально опасна"

Это как я понимаю пример "как ни надо делать" =) Будемс знать.

↑

Это пример того, что цикл символических ссылок можно отследить.

[t.t]

Хард линки на папки просто так может создать только рут.

↑

Я бы тут кое-что уточнил:

В существующих реализациях, если команда ln может создавать жесткую ссылку на каталог, то она может это делать только от лица суперпользователя. POSIX запрещает системному вызову link(2) и утилите ln создавать жесткие ссылки на каталоги

Код: Выделить всё

# ln new/ 1
ln: `new/': не допускается создавать жесткие ссылки на каталоги
$ ln --version
ln (GNU coreutils) 5.97
Copyright (C) 2006 Free Software Foundation, Inc.

2codec:
Кстати, насчёт жёстких ссылок. Для ясности нужно было добавлять "второй хардлинк", потому как первоначальное "имя файла" на самом деле тоже является жёсткой ссылкой на этот файл. При создании второй жёсткой ссылки на тот же файл она становится полностью равноправной с первой; то есть файл имеет два "имени". То есть к примеру с точки зрения конечного результата команды "cp 1 2 && rm 1" и "ln 1 2 && rm 1" совершенно идентичны (с точностью до физического размещения файла на диске, но так глубоко лезть нет смысла). А файл считается удалённым, когда на него не осталось _ни одной_ жёсткой ссылки. Вообще, у всей этой системы со ссылками (жёсткими и мягкими) плюсов значительно больше, чем минусов.

[unflag]

2codec:
Если вам так не нравятся линки, то сделайте

Код: Выделить всё

alias ln='echo низя'

И не мучайтесь
А все уже созданные хардлинки удалите. Только вот что хорошего у вас получится после такого членовредительства - вопрос еще тот. Собственно, а почему вы решили, что линки уродуют структуру фс? Может быть, ваше видение её как раз и есть неправильно?

[codec]

Да я не мучаюсь. И удалять ничего не собираюсь. Просто хочу понять что как и почему сделано =)

"cp 1 2 && rm 1" и "ln 1 2 && rm 1" совершенно идентичны (с точностью до физического размещения файла на диске, но так глубоко лезть нет смысла)

Хм. А вот тут мне не совсем ясно, почему именно с точностью до физического размещения на диске.
В соответствии с Bash Reference, пункт 3.2.3 Lists of Commands.

A list is a sequence of one or more pipelines separated by one of the operators `;', `&', `&&', or `||', and optionally terminated by one of `;', `&', or a newline.
...
command1 && command2

command2 is executed if, and only if, command1 returns an exit status of zero.

по идее
"cp 1 2 && rm 1" - сначала должна быть создана физически новая копия файла 1, потом создан хард линк на 2, а потом удален хард линк на 1.
а
"ln 1 2 && rm 1" - создан второй хард линк 2 на файл 1 (который физически никуда не двигался), а потом удален хард линк 2.

Или я чтото не так понимаю?

[polachok]

"ln 1 2 && rm 1" - создан второй хард линк 2 на файл 1 (который физически никуда не двигался), а потом удален хард линк 2.

почему - 2 ?

[t.t]

по идее
"cp 1 2 && rm 1" - сначала должна быть создана физически новая копия файла 1, потом создан хард линк на 2, а потом удален хард линк на 1.
а
"ln 1 2 && rm 1" - создан второй хард линк 2 на файл 1 (который физически никуда не двигался), а потом удален хард линк 2.

↑

Правильно с точностью до поправки, на которую намекает полячок. Если подробнее: в первом случае жёсткая ссылка 2 создаётся на физическую копию файла, после чего первая ссылка удаляется, а то, на что она ссылалась, как файл больше недоступно (но физически данные никуда не делись, пока не будут затёрты); во втором ничего никуда не копировалось -- это почти полный аналог "mv 1 2". Т.е. физически разница между этими двумя вариантами будет: в первом случае файл 2 будет лежать в другом месте, а по старому расположению останется недоступная копия, которая отныне будет восприниматься как свободное место. А на пользовательском уровне разницы никакой (между результатами, а не действиями): в обоих случаях файл, доступный ранее под именем 1, теперь будет доступен под именем 2.

[codec]

почему - 2 ?

Это просто опечатка. Я хотел написать там 1.

2 t.t.
Так всетаки на физическом уровне операции таки разные как я и полагал.

2 Bruce
Зачем это надо я и так понимаю. Спасибо.