[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210616105655.5129-1-jack@suse.cz>
Date: Wed, 16 Jun 2021 12:56:51 +0200
From: Jan Kara <jack@...e.cz>
To: Ted Tso <tytso@....edu>
Cc: <linux-ext4@...r.kernel.org>, Jan Kara <jack@...e.cz>
Subject: [PATCH 0/4 v3] ext4: Speedup orphan file handling
Hello,
After six years, prompted by recent 0-day reports of performance issues with
orphan list handling [1], I'm sending a third revision of my series to speed up
orphan inode handling in ext4.
Orphan inode handling in ext4 is a bottleneck for workloads which heavily
excercise truncate / unlink of small files as they contend on global
s_orphan_mutex (when you have fast enough storage). This patch set implements
new way of handling orphan inodes - instead of using a linked list, we store
inode numbers of orphaned inodes in a file which is possible to implement in a
more scalable manner than linked list manipulations. See description of patch
3/4 for more details.
The patch set achieves significant gains both for a micro benchmark stressing
orphan inode handling (truncating file byte-by-byte, several threads in
parallel) and for reaim creat_clo workload. I'm happy for any review, thoughts,
ideas about the patches. I have also implemented full support in e2fsprogs
which I'll send separately.
Honza
[1] https://lore.kernel.org/lkml/20210227120804.GB22871@xsang-OptiPlex-9020/
Changes since v2:
* Updated some comments
* Rebased onto 5.13-rc5
* Change orphan file inode from a fixed inode number to inode number stored
in the superblock
Changes since v1:
* orphan blocks have now magic numbers
* split out orphan handling to a separate source file
* some smaller updates according to review
Powered by blists - more mailing lists