Гарантируется ли (например, стандартом) неизменность номера инода после перезагрузки, перемонтирования или даже после того, как он был закрыт всеми процессами, а затем снова открыт? Например. может ли он автоматически генерироваться при открытии файла, а не храниться в файловой системе. Может ли приложение полагаться на него? Должна ли реализация файловой системы гарантировать определенную семантику?
Номер инода после перезагрузки
comment
Как вы собираетесь его использовать? Не существует пользовательского API, который принимает номер инода (и, предположительно, номер устройства, поскольку уникальна только комбинация) и возвращает имя файла или дескриптор файла. Это зарезервировано для кода файловой системы в ядре. Вы можете быть уверены, что если номер инода отличается от того, что был до перезагрузки, файл был изменен. Вы не можете быть настолько уверены, если номер инода тот же; все, что вы знаете, это то, что одно и то же имя сопоставляется с одним и тем же номером, но в промежутке могли быть удалены и воссозданы - у индексного дескриптора также могли быть другие имена.
- person Jonathan Leffler schedule 14.01.2014
comment
В первую очередь я рассматриваю требования к драйверу файловой системы. Есть ли у драйвера FS возможность создавать номера инодов при чтении дерева каталогов, или он сломает приложения. Еще лучше, есть ли стандарт и не нарушит ли он ожидаемую семантику. Ваш комментарий, кажется, предполагает, что inode является указателем на удобство файловой системы, и на него нельзя строго полагаться. ... Разрешено ли ls -i выводить разные индексы, если файлы не изменялись?
- person Martin schedule 15.01.2014
comment
Я не знаю, обязательно ли есть какая-либо необходимая семантика для номеров инодов, но я знаю, что 1) не все файловые системы даже имеют понятие инода, и поэтому любые номера инодов, которые вы можете получить от них, имеют тенденцию быть синтетическими, и 2) в большинстве файловых систем номера inode, как правило, являются статическими, иногда выделяются и индексируются при создании файловой системы, иногда в зависимости от места на диске, где они хранятся, и т. д. Вероятно, так проще...
- person twalberg schedule 15.01.2014
Ответы (1)
inode не является общей концепцией для всех файловых систем. Ext, а Linux VFS рассматривает inode как структуру данных, в которой хранится информация о файле. Но, например, FAT32 или NTFS понятия не имеют, что такое inode, потому что они просто не используют это понятие.
Сказав это, я постараюсь дать ответы на ваши вопросы:
Гарантируется ли (например, стандартом) неизменность номера инода после перезагрузки, перемонтирования или даже после того, как он был закрыт всеми процессами, а затем снова открыт?
Зависит от того, если файловая система типа Ext, то номер inode хранится в файле i_ino внутри struct inode, который записывается на диск, так что да, в этом случае, если файл тот же (не другой файл с тем же именем), то номер inode гарантированно будет таким же.
В противном случае, если файловая система отличается от Ext, номер inode генерируется inode operations, определенным драйвером файловой системы, поскольку у них нет понятия о том, что такое inode, они должны имитировать все внутренние поля inode, чтобы соответствовать VFS. , поэтому это число, вероятно, будет другим после перезагрузки, даже после закрытия и повторного открытия файла (теоретически).
Например. может ли он автоматически генерироваться при открытии файла, а не храниться в файловой системе.
Да! Драйверы файловой системы, отличной от Ext (FAT32, NTFS), генерируют структуру inode всякий раз, когда осуществляется доступ к одному из ее файлов.
Может ли приложение полагаться на него?
Не очень безопасно, приложения полагаются на пути к файлам, которые более удобочитаемы. Необходимость найти файл по его inode будет означать перебор всех inodes в разделе (много-много). Разрешая путь к файлу, поиск оптимизируется, он проверяет только файлы внутри каталогов.
Должна ли реализация файловой системы гарантировать определенную семантику?
Я не очень хорошо понимаю этот вопрос, но я предполагаю, что да, файловые системы - это очень сложные структуры, им нужно хорошо определить, какие типы данных потребуются и каково будет их значение.
Например: Ext определяет block, inode и dentry, а также список функций над этими структурами данных.
Надеюсь это поможет!
person
Paulo Bu
schedule
14.01.2014
Знаете ли вы пример файловой системы, которая генерирует разные номера инодов для одного и того же файла во время одного сеанса монтирования?
- person Martin; 15.01.2014
Я не могу сказать точно, но вы можете попробовать сами. Смонтируйте диск FAT32 или NTFS в Linux, немного поиграйтесь с файлами, делая
ls -i после каждого изменения. Вероятно, они не изменятся, потому что будут закэшированы, но они точно нереальны.
- person Paulo Bu; 15.01.2014
Из того, что я видел, в fat и ntfs иноды не изменятся, они будут сопоставлены либо указателю на жир, либо номеру кластера для ntfs. Я надеялся, что у кого-то есть ответ, и мне не нужно тратить недели на то, чтобы поиграться с каждой отдельной файловой системой, а затем обнаружить, что BSD имеет семантику, отличную от Linux, или что POSIX говорит что-то конкретное, что требуется, что либо не реализованы или трудно соблюдаются.
- person Martin; 15.01.2014
Ни один, наверное, не изменился бы. Менять его — операция дорогая и совсем не нужная. ОС, вероятно, кэширует его в первый раз и поддерживает. Попробуйте почитать что-нибудь о VFS.
- person Paulo Bu; 15.01.2014
@Martin только что сделал в Linux,
touch x, создал и поместил в индекс с идентификатором 294959, затем rm x, touch y и индекс для y повторно использовал идентификатор 294959. Это что-то говорит?
- person Paulo Bu; 15.01.2014
Повторное использование индексов для нового файла после удаления старого файла — это не то же самое, что получение другого индекса для того же файла. Почти все файловые системы на основе инодов будут повторно использовать иноды...
- person twalberg; 15.01.2014
@twalberg Я знаю, я просто пытался подчеркнуть, что
id небезопасно использовать в приложениях.
- person Paulo Bu; 15.01.2014
Спасибо за эксперимент, но он не помогает. Меня больше беспокоит файл, который не был удален внезапно, с другим номером инода. Может быть, NFS или samba, но я не ожидал увидеть это легко на дисковой FS. Вопрос был в том, ожидается ли, что это никогда не произойдет?
- person Martin; 15.01.2014
Я могу дать вам следующий ответ: С файловыми системами, имеющими понятие
inode, этого не ожидается, с другими файловыми системами теоретически это может произойти, но вы редко это увидите.
- person Paulo Bu; 15.01.2014
