Фактическое содержимое файла символической ссылки
Для
ip rule add table 128 from 192.168.10.123:
.ip ruleуправляет правилами маршрутизации. Требуется как SELECTOR , так и ACTION . Таким образом, в этом случае СЕЛЕКТОР — этоfrom 192.168.10.123(192.168.10.123 — это ПРЕФИКС ), а ДЕЙСТВИЕ — этоtable 128. В целом это говорит: «Добавьте правило маршрутизации дляtable 128для трафика, поступающего из192.168.10.123Для
ip route add table 128 to 192.168.10.0/24 dev eth0:Команда
ip routeманипулирует целыми таблицами маршрутизации(в вашем случаеtable 128манипулирует). Выaddвводите правило, которое гласит: «Весь трафик, предназначенный для192.168.10.0/24, использует устройство выводаeth0.Для
ip route add table 128 default via 192.168.10.1Как и прежде, команда
ip routeуправляет маршрутомtable 128. Но здесь маршрут говорит: «Направьте весь трафик(default= IP0/0 или IPv6 ::/0)на адрес маршрутизатора следующего перехода192.168.10.1. (. ] Скорее всего, это шлюз по умолчанию в вашей частной сети.)
Я надеюсь, что такое объяснение будет для вас более полезным, чем запутанным.
Вы не предоставили дополнительных сведений, поэтому это объяснение на данный момент сосредоточено на файловых системах EXT, распространенных в Linux.
Если вы посмотрите на «размер» символической ссылки, как это предусмотрено, например. ls -l, вы заметите, что размер такой же большой, как и длинное имя цели, на которую он указывает. Таким образом, вы можете сделать вывод, что «фактический» файл содержит только путь к цели ссылки в виде текста, а интерпретация символической ссылки хранится в метаданных типа файла (, в частности, флаг S_IFLINKв i_modeполе индекса, к которому прикреплен файл ссылки, где также хранятся биты разрешения; см. эту ссылку на документацию по ядру ).
Чтобы повысить производительность и уменьшить количество операций ввода-вывода устройства, если символическая ссылка короче 60 байт, она будет храниться в поле i_blockв самом индексном узле (см. здесь). Поскольку это делает ненужным доступ к отдельному блоку, эти ссылки называются «быстрыми символическими ссылками», в отличие от символических ссылок, указывающих на более длинные пути, которые возвращаются к «традиционному» методу хранения цели ссылки в виде текста во внешнем блоке данных.
Это полностью зависит от файловой системы.
Обычно цель символической ссылки хранится как -в дополнительном пространстве блока индексных дескрипторов, точно так же, как небольшие каталоги и небольшие файлы.Нет необходимости в каком-либо специальном формате данных --, биты режима файла уже определяют, что это символическая ссылка и должна рассматриваться как таковая. Целью является «фактическое содержимое» :, которое вы можете использовать readlink -n /path/to | hexdump, если вы действительно хотите использовать hexdump.
При вызове lstat (2 )для символической ссылки st.st_sizeбудет содержать длину цели (, не включая завершающий NUL-байт ).
Использование hexdumpдля символической ссылки вообще не смотрит на файловую систему ext4. Он смотрит на приложение -, сталкивающееся с абстракцией. На этом слое ничего не видно. Открытие символической ссылки либо попытается открыть то, на что она ссылается, в соответствии с семантикой разрешения пути (нет O_NOFOLLOW), либо потерпит неудачу(O_NOFOLLOW). Способ чтения содержимого на этом уровне абстракции — readlink, и он просто даст вам последовательность байтов, которые были переданы на symlinkдля его создания. Это ничего не говорит вам о том, как оно представлено на диске.
Чтобы изучить представление на диске, вам нужно открыть (или использовать инструмент, открывающий )блочное устройство, и пройтись по структурам файловой системы, пока не дойдете до символической ссылки, которую хотите увидеть. Я полагаю, что ext4 хранит небольшие -символические ссылки содержимого, встроенные в структуру инодов (без отдельного блока данных на диске ), а большие хранит просто как файл, содержащий содержимое ссылки, но с типом символической ссылки.