Как номера инодов генерируются в linux tmpfs?

Мне кажется, что tmpfs не использует номера инодов повторно, а создает новый номер инода через последовательность +1 каждый раз, когда ему нужен свободный инод.

Знаете ли вы, как это реализовано / можете ли вы указать мне какой-нибудь исходный код, где я мог бы проверить алгоритм, который используется в tmpfs?

Мне нужно понять это, чтобы обойти ограничение в системе кеширования, которая использует номер инода в качестве ключа кеша (что приводит к редким, но встречающимся коллизиям, когда иноды используются слишком часто). tmpfs может спасти мой день, если я смогу доказать, что он продолжает создавать уникальные номера inode.

Спасибо за помощь,

Джером Вагнер

2 ответа

Решение

Основная часть кода tmpfs находится в mm/shmem.c, Новые иноды создаются

static struct inode *shmem_get_inode(struct super_block *sb, const struct inode *dir,
                                 int mode, dev_t dev, unsigned long flags)

но он делегирует почти все в общий код файловой системы.

В частности, поле i_ino заполнен в fs/inode.c:

/**
 *      new_inode       - obtain an inode
 *      @sb: superblock
 *
 *      Allocates a new inode for given superblock. The default gfp_mask
 *      for allocations related to inode->i_mapping is GFP_HIGHUSER_MOVABLE.
 *      If HIGHMEM pages are unsuitable or it is known that pages allocated
 *      for the page cache are not reclaimable or migratable,
 *      mapping_set_gfp_mask() must be called with suitable flags on the
 *      newly created inode's mapping
 *
 */
struct inode *new_inode(struct super_block *sb)
{
        /*
         * On a 32bit, non LFS stat() call, glibc will generate an EOVERFLOW
         * error if st_ino won't fit in target struct field. Use 32bit counter
         * here to attempt to avoid that.
         */
        static unsigned int last_ino;
        struct inode *inode;

        spin_lock_prefetch(&inode_lock);

        inode = alloc_inode(sb);
        if (inode) {
                spin_lock(&inode_lock);
                __inode_add_to_lists(sb, NULL, inode);
                inode->i_ino = ++last_ino;
                inode->i_state = 0;
                spin_unlock(&inode_lock);
        }
        return inode;
}

И он действительно просто использует увеличивающийся счетчик (last_ino).

Большинство других файловых систем используют информацию из файлов на диске для последующего переопределения i_ino поле.

Обратите внимание, что это вполне возможно, чтобы обернуть все вокруг. Ядро также имеет поле "поколения", которое заполняется различными способами. mm/shmem.c использует текущее время.

Я не буду прямо отвечать на ваш вопрос, поэтому заранее прошу прощения за это.

Идея tmpfs хороша, но я бы не хотел, чтобы моя программа зависела от более или менее неясных деталей реализации генерации ключей. Почему бы вам не попробовать другой метод, например, объединить номер индекса с другой информацией? Может быть дата модификации: невозможно, чтобы два файла получали одинаковый номер инода И дату модификации во время генерации ключа, если только системная дата не изменяется.

Ура!

Другие вопросы по тегам