Есть ли какие-либо побочные эффекты при создании символической ссылки на другую символическую ссылку?

Ответ 1

В общем, нет. Технически, для косвенности будет очень небольшой удар по производительности, но это не будет заметно для вашего приложения. В качестве примера большинство разделяемых библиотек являются символическими ссылками на символические ссылки (например, libQtCore.so → libQtCore.so.4 → libQtCore.so.4.7 → libQtCore.so.4.7.1).

Ответ 2

Это в основном комментарий к аргументу Даниэля Галлахера, но он не подходит в поле комментариев, поэтому это сделает его более читаемым. Из Википедия по символическим ссылкам:

Ранние реализации символических ссылок сохраняли символическую информацию о ссылках как данные в обычных файлах. Файл содержал текстовую ссылку на цель ссылок и индикатор [необходимый пояснение], обозначающий его как символическую ссылку.

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

Хотя сохранение значения ссылки внутри inode сохраняет блок диска и чтение диска, операционной системе по-прежнему необходимо проанализировать имя пути в ссылке, что всегда требует чтения дополнительных инодов и, как правило, требует чтения других и, возможно, многих, каталогов, обрабатывая как список файлов, так и индексные дескрипторы каждого из них, пока не найдет совпадение с компонентами пути линии. Только когда ссылка указывает на файл в том же каталоге, "быстрые символические ссылки" обеспечивают значительно лучшую производительность, чем другие символические ссылки.

Таким образом, штраф за использование символических ссылок на символические ссылки для библиотек в /usr/lib менее серьезен, чем более длинные поиски путей, которые, возможно, даже охватывают несколько точек монтирования.

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

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

Ответ 3

побочные эффекты

Да. Вы можете объединять столько символических ссылок, прежде чем ядро ​​и/или приложение откажутся следовать цепочке. (Поскольку обнаружение цикла является дорогостоящим по памяти, особенно в ядре, не используются "видимые" флаги, а глубина рекурсии ограничена.)