Hi all, This series fixes a couple of bugs that I found in log recovery. The first problem is that we don't reserve space for per-AG btree expansion when we inactivate inodes during log recovery. If a file with shared blocks were to be unlinked, this can result in transaction failure because inactivation assumes that it doesn't need to reserve blocks to free files and cannot handle a refcount btree expansion. The second problem addressed here is that if log recovery fails due to something that doesn't directly impact the log (like ENOSPC during transaction allocation, or ENOMEM allocating buffers) it will leave the log running, which means that it writes an unmount record after recovery fails. The /next/ mount will see a clean log and start running, even though the metadata isn't consistent. If you're going to start using this mess, you probably ought to just pull from my git trees, which are linked below. This is an extraordinary way to destroy everything. Enjoy! Comments and questions are, as always, welcome. --D kernel git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=log-recovery-fixes-5.14 --- fs/xfs/xfs_log.c | 3 +++ fs/xfs/xfs_log_recover.c | 5 ++++- fs/xfs/xfs_mount.c | 10 +++++++++- 3 files changed, 16 insertions(+), 2 deletions(-)
