Received-SPF: pass (google.com: domain of linux-kernel+bounces-123001-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
From: Johannes Thumshirn <jth@kernel.org>
Subject: [PATCH RFC 0/3] btrfs: zoned: reclaim block-groups more
 aggressively
Date: Thu, 28 Mar 2024 14:56:30 +0100
Message-Id: <20240328-hans-v1-0-4cd558959407@kernel.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>, 
 David Sterba <dsterba@suse.com>
Cc: linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, 
 Hans Holmberg <Hans.Holmberg@wdc.com>, Naohiro Aota <Naohiro.Aota@wdc.com>, 
 hch@lst.de, Damien LeMoal <dlemoal@kernel.org>, Boris Burkov <boris@bur.io>, 
 Johannes Thumshirn <johannes.thumshirn@wdc.com>

Recently we had reports internally that zoned btrfs can get to -ENOSPC
prematurely, because we're running out of allocatable zones on the drive.

But we would have enough space left, if we would reclaim more aggressively.

The following fio-job is an example how to trigger the failure.

[test]
filename=$SCRATCH_MNT
readwrite=write
ioengine=libaio
direct=1
loops=2
filesize=$60_PERCENT_OF_DRIVE
bs=128k

The reason this is still an RFC is, it is enough to have DATA block groups
free but not METADATA block groups. Of cause the same principle could be
applied to METADATA block groups as well, but I'd prefer to have a
discussion on the general direction first.

---
Johannes Thumshirn (3):
      btrfs: zoned: traverse device list in should reclaim under rcu_read_lock
      btrfs: zoned: reserve relocation zone on mount
      btrfs: zoned: kick cleaner kthread if low on space

 fs/btrfs/disk-io.c |  2 ++
 fs/btrfs/zoned.c   | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++--
 fs/btrfs/zoned.h   |  3 +++
 3 files changed, 59 insertions(+), 2 deletions(-)
---
base-commit: c22750cb802ea5fd510fa66f77aefa3a0529951b
change-id: 20240328-hans-2c9e3b4a69e8

Best regards,
-- 
Johannes Thumshirn <jth@kernel.org>