Intereting Posts
В Linux, как вы видите, что делает другой процесс, если в этом процессе нет журналов? Привязать ALT ключ в Tmux для перемещения по панелям Настройте определенную частоту с моей беспроводной карты `sudo cp -a` изменяет право собственности на root (вместо сохранения исходного пользователя) Как удалить информацию о масштабировании из закладки PDF установка квоты на zfs не работает Как игнорировать тип mime для расширения файла maff? Перенос файлов из CentOS VM VirtualBox на хост-машину Windows Единственный способ отключить / включить Wi-Fi – перевести ноутбук в спящий режим CentOS 7 – Принуждение диска быть / dev / sda Где настройки pm-powersave на OpenSUSE 13.2 и используются ли они? Что может привести к тому, что не показывать что-то в пути? Как получить все номера из строки и добавить их? Количество строк с определенным значением в столбце для всех файлов в каталоге рекурсивно tar-экстракт зависает от несуществующего файла

Для чего полезны иноды?

Интересно, стоит ли хранить информацию о файлах в inodes, а не непосредственно в каталоге, дополнительные расходы. Может быть, хорошо, что я переоцениваю накладные расходы или игнорирую какую-то важную вещь, но именно поэтому я спрашиваю.

Я вижу, что для жестких ссылок необходимо что-то вроде «inodes», но если накладные расходы действительно такие большие, как я думаю, мне интересно, оправдывает ли какая-либо из причин :

  • использование жестких ссылок для резервных копий является умным, но эффективность резервных копий недостаточно важна по сравнению с эффективностью обычных операций
  • отсутствие ограничений скорости и размера для жестких ссылок действительно может иметь значение, поскольку это преимущество имеет место только для нескольких файлов, использующих жесткие ссылки, в то время как доступ ко всем файлам страдает от накладных расходов
  • сохранение некоторого пространства для пары одинаково названных двоичных файлов, таких как bunzip2 и bcat , незначительно

Я не говорю, что inodes / hardlinks плохи или бесполезны, но могут ли они оправдывать стоимость дополнительной косвенности (кеширование помогает, конечно, много, но это не серебряная пуля)?

Жесткие ссылки – кроме того. Они не являются причиной наличия inodes. Они являются побочным продуктом: в принципе, любой разумный unix-подобный дизайн файловой системы (и даже NTFS достаточно близок к этому вопросу) имеет жесткие ссылки бесплатно.

Индекс – это место, где хранятся все метаданные файла: время его модификации, его разрешения и т. Д. Это также место хранения данных файла на диске. Эти данные должны быть где-то сохранены.

Сохранение данных inode внутри каталога несет свои собственные служебные данные. Это делает каталог более крупным, так что получение списка каталогов происходит медленнее. Вы сохраняете поиск для каждого доступа к файлам, но каждый обход каталога (из которого несколько необходимы для доступа к файлу, по одному в каталоге по пути к файлу) стоит немного больше. Самое главное, что перемещать файл из одного каталога в другой гораздо сложнее: вместо перемещения только указателя на индексный дескриптор необходимо перемещать все метаданные.

Unix-системы всегда позволяют вам переименовывать или удалять файл, даже если процесс открыт. (В некоторых вариантах unix делайте это почти всегда.) Это очень важное свойство на практике: это означает, что приложение не может «захватить» файл. Переименование или удаление файла не влияет на приложение, оно может продолжать чтение и запись в файл. Если файл удаляется, данные остаются до тех пор, пока процесс не будет открыт. Этому способствует ассоциация процесса с inode. Этот процесс не может быть связан с именем файла, поскольку он может измениться или даже исчезнуть в любое время.

См. Также Что такое Superblock, Inode, Dentry и файл?

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

У меня есть копия «Технического журнала Bell System», июль-август 1978 года. Это одна из их специальных проблем, и она называется «Unix Time Sharing System». Это то место, где Томпсон, Ричи и компания опубликовали свое описание версий 6 и 7 Unix и что вы могли с ним сделать.

Я вижу описания inodes и файловой системы, но никаких мотивов для дизайна. Ритчи и Томпсон отмечают, что системный вызов create (их орфография в BSTJ) делает inode и устанавливает значения, в то время как open системные вызовы заполняют таблицы OS, которые могут хранить данные inode для дальнейшего доступа к файлам.

Один из ключевых параграфов говорит о куске дисков inodes, которые они назвали i-list:

Понятие i-списка является необычной особенностью UNIX. На практике этот способ организации файловой системы оказался достаточно надежным и легким в обращении. … Он также позволяет довольно простой и быстрый алгоритм проверки согласованности файловой системы … Этот алгоритм не зависит от иерархии каталогов, поскольку ему нужно только сканировать линейно организованный i-list.

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

Я считаю, что мы можем указать на многолетний опыт, сделавший это правдой. MS-DOS и другие файловые системы, где иерархия каталогов смешана с распределением (FAT), довольно хрупкие. Если сектор в FAT идет плохо, все очень сложно восстановить. Но если сектор в каталоге идет не так, то inode, где-то еще на диске, все еще существует, с подсчетом ссылок, который указывает, что он принадлежит к некоторому каталогу и, следовательно, может быть восстановлен.

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

1 практический пример inode:

у вас есть файл с хитрым именем (пример ~ *), и вам нужно его удалить.

 ls ~* 

rm -rf ~* наносит ущерб вашему $ HOME, поэтому вам нужно удалить его по-другому.

Читайте здесь, как удалить файлы по inode.

Удалить файл по inode:

 find . -type f -inum 1234 - exec rm -rf {} /; 

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

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