Deep Dive into the Linux rm Command: VFS, ext4 Unlink Process and I/O Impact

When the rm command is executed, it ultimately invokes the Linux unlink system call, which triggers a series of VFS and ext4 operations inside the kernel. The article examines this flow on a Linux‑3.10.104 kernel with an ext4 filesystem.

The unlink syscall is defined as:

SYSCALL_DEFINE1(unlink, const char __user *, pathname)
{
    return do_unlinkat(AT_FDCWD, pathname);
}

The do_unlinkat function performs path resolution, permission checks, and then calls vfs_unlink . Key structures involved are inode (file metadata), dentry (directory entry), and the dentry cache (dcache) which speeds up lookups.

Inside vfs_unlink , the ext4‑specific ext4_unlink is invoked, followed by d_delete to remove the dentry from the cache. Subsequent calls to dput and iput manage reference counts and eventually free the inode via the evict path:

evict() --> ext4_evict_inode() --> ext4_truncate() --> ext4_ext_truncate() --> ext4_ext_remove_space() --> ext4_ext_rm_leaf() --> ext4_free_blocks()

Ext4 uses extents instead of indirect block pointers. The extent header and extent structures are defined as:

struct ext4_extent_header {
    __le16 eh_magic;
    __le16 eh_entries;
    __le16 eh_max;
    __le16 eh_depth;
    __le32 eh_generation;
};

struct ext4_extent {
    __le32 ee_block;
    __le16 ee_len;
    __le16 ee_start_hi;
    __le32 ee_start_lo;
};

struct ext4_extent_idx {
    __le32 ei_block;
    __le32 ei_leaf_lo;
    __le16 ei_leaf_hi;
    __u16 ei_unused;
};

When a file is large, ext4 builds an extent tree using ext4_extent_idx nodes; the depth field in the header indicates the presence of such indexes. Deleting a file ultimately frees the blocks via ext4_free_blocks , which clears the corresponding bits in the block bitmap and updates quota information.

Block freeing also marks the inode dirty and writes metadata to the journal. The dirty‑inode handling involves functions like ext4_dirty_inode , which starts a journal transaction, updates the on‑disk inode, and then stops the transaction.

void ext4_dirty_inode(struct inode *inode, int flags)
{
    handle_t *handle;
    handle = ext4_journal_start(inode, EXT4_HT_INODE, 2);
    if (IS_ERR(handle))
        goto out;
    ext4_mark_inode_dirty(handle, inode);
    ext4_journal_stop(handle);
out:
    return;
}

The article then measures the I/O impact of deleting a large file. Using Sysbench to stress MySQL on an NVMe SSD, the average QPS drops from about 205 500 (no deletion) to roughly 40 500 when a 400 GB file is removed, showing that extensive journal updates and block bitmap changes can significantly affect other I/O‑intensive workloads.

To mitigate this, the author suggests truncating the large file in smaller chunks with pauses between operations, thereby spreading the I/O load and avoiding a sudden spike.

References:

https://www.ibm.com/developerworks/cn/linux/l-cn-usagecounter/

https://digital-forensics.sans.org/blog/2010/12/20/digital-forensics-understanding-ext4-part-1-extents

http://blog.csdn.net/luckyapple1028/article/details/61413724