VFS: общий интерфейс для любой файловой системыVFS: a common interface for any filesystem

VFS (Virtual File System) — не файловая система в обычном смысле, а слой абстракции внутри ядра, через который проходит любой доступ к файлам. Когда приложение вызывает open(), read() или mkdir(), эти вызовы попадают не напрямую в код ext4 или Btrfs, а в общий код VFS, который определяет, какая именно файловая система отвечает за нужный путь, и вызывает её конкретную реализацию через таблицу операций. Это тот же архитектурный приём, что и в объектно-ориентированном полиморфизме — только вместо vtable компилятора здесь обычные C-структуры с указателями на функции, заполняемые модулем файловой системы при инициализации.VFS (Virtual File System) isn't a filesystem in the usual sense — it's an abstraction layer inside the kernel that every file access passes through. When an application calls open(), read(), or mkdir(), those calls don't go directly into ext4 or Btrfs code — they go into common VFS code, which figures out which filesystem actually owns the requested path and calls its specific implementation through an operations table. It's the same architectural trick as object-oriented polymorphism — except instead of a compiler-generated vtable, it's plain C structs with function pointers, filled in by the filesystem module at initialization.

Связь между четырьмя объектами — не плоский список, а граф, который строится по мере того, как ядро разрешает путь компонент за компонентом:The relationship between the four objects isn't a flat list — it's a graph, built as the kernel resolves a path component by component:

Ключевой механизм — таблицы операций. Каждый объект несёт указатель на структуру функций-указателей, и именно эти таблицы заполняет модуль конкретной ФС при регистрации:The key mechanism is operations tables. Every object carries a pointer to a struct of function pointers, and it's exactly these tables that a specific filesystem's module fills in when it registers:

// super_operations — операции над самой смонтированной ФС
struct super_operations {
    struct inode *(*alloc_inode)(struct super_block *sb);
    void (*destroy_inode)(struct inode *);
    int (*write_inode)(struct inode *, struct writeback_control *);
    void (*put_super)(struct super_block *);
    int (*statfs)(struct dentry *, struct kstatfs *);
};

// inode_operations — операции над деревом каталогов (создание/поиск/удаление)
struct inode_operations {
    struct dentry *(*lookup)(struct inode *, struct dentry *, unsigned int);
    int (*create)(struct mnt_idmap *, struct inode *, struct dentry *, umode_t, bool);
    int (*mkdir)(struct mnt_idmap *, struct inode *, struct dentry *, umode_t);
    int (*unlink)(struct inode *, struct dentry *);
};

// file_operations — операции над уже открытым файлом (I/O)
struct file_operations {
    ssize_t (*read)(struct file *, char __user *, size_t, loff_t *);
    ssize_t (*write)(struct file *, const char __user *, size_t, loff_t *);
    int (*open)(struct inode *, struct file *);
    int (*fsync)(struct file *, loff_t, loff_t, int datasync);
};

Когда приложение вызывает read(fd, buf, count), ядро находит по дескриптору fd объект file, берёт из него f_op — указатель на таблицу file_operations, заполненную ext4 (или Btrfs, или tmpfs) при монтировании, — и вызывает f_op->read(...). Код системного вызова read() в VFS ни разу не упоминает ext4 напрямую: он просто разыменовывает указатель на функцию, которая может вести куда угодно, вплоть до сетевого запроса в случае NFS.When an application calls read(fd, buf, count), the kernel looks up the file object by descriptor fd, takes f_op from it — a pointer to the file_operations table filled in by ext4 (or Btrfs, or tmpfs) at mount time — and calls f_op->read(...). The VFS read() syscall code never mentions ext4 by name: it just dereferences a function pointer that can lead anywhere, up to and including a network request in NFS's case.

Второй ключевой механизм — кэши, без которых VFS был бы слишком медленным для практического использования:The second key mechanism is the caches, without which VFS would be too slow for practical use:

Оба кэша работают на уровне VFS, а не отдельно для каждой файловой системы — это значит, что горячий путь (повторное открытие того же файла, повторное чтение того же блока) почти никогда не касается кода ext4 или Btrfs напрямую и уж тем более физического диска. С Linux 2.6.38 большинство попаданий в dcache идут по RCU-пути без единой блокировки — конкурентные lookup'ы не сериализуются спинлоком на общем (кэш-попадание) пути.Both caches operate at the VFS level, not separately per filesystem — meaning the hot path (reopening the same file, rereading the same block) almost never touches ext4 or Btrfs code directly, let alone the physical disk. Since Linux 2.6.38, most dcache hits go through an RCU path with no locking at all — concurrent lookups aren't serialized by a spinlock on the common (cache-hit) path.

• kernel.org docs — Overview of the Linux Virtual File System
• Linux Kernel Internals — VFS Objects