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

Question

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

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

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

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

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

Answer 1

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

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

Ура! * * 1005

Answer 2

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

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 использует текущее время.