On Mon, Sep 25, 2023 at 02:59:39PM -0700, Darrick J. Wong wrote: > Hi all, > > It turns out that there are some serious bugs in how xfs handles the > unlinked inode lists. Way back before 4.14, there was a bug where a ro > mount of a dirty filesystem would recover the log bug neglect to purge > the unlinked list. This leads to clean unmounted filesystems with > unlinked inodes. Starting around 5.15, we also converted the codebase > to maintain a doubly-linked incore unlinked list. However, we never > provided the ability to load the incore list from disk. If someone > tries to allocate an O_TMPFILE file on a clean fs with a pre-existing > unlinked list or even deletes a file, the code will fail and the fs > shuts down. > > This first part of the correction effort adds the ability to load the > first inode in the bucket when unlinking a file; and to load the next > inode in the list when inactivating (freeing) an inode. > > In userspace, we'll add a xfs_db command to create unlinked inodes on a > (presumably) clean filesystem so that we can finally write some > regression and functional testing of iunlink recovery to ensure that > this all works properly. > > If you're going to start using this code, I strongly recommend pulling > from my git trees, which are linked below. > > This has been running on the djcloud for months with no problems. Enjoy! > Comments and questions are, as always, welcome. > For the series: Reviewed-by: Carlos Maiolino <cmaiolino@xxxxxxxxxx> Carlos > --D > > kernel git tree: > https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=fix-iunlink > > xfsprogs git tree: > https://git.kernel.org/cgit/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=fix-iunlink > --- > db/Makefile | 2 > db/command.c | 1 > db/command.h | 1 > db/iunlink.c | 400 ++++++++++++++++++++++++++++++++++++++++++++++ > libxfs/libxfs_api_defs.h | 2 > man/man8/xfs_db.8 | 30 +++ > 6 files changed, 435 insertions(+), 1 deletion(-) > create mode 100644 db/iunlink.c >
