Для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 хранит небольшие -символические ссылки содержимого, встроенные в структуру инодов (без отдельного блока данных на диске ), а большие хранит просто как файл, содержащий содержимое ссылки, но с типом символической ссылки.