Re: [LSF/MM/BPF TOPIC]: File system data placement for zoned block devices

From: Boris Burkov <boris@bur.io>
To: Hans Holmberg <hans@owltronix.com>
Cc: "Johannes Thumshirn" <Johannes.Thumshirn@wdc.com>,
	"Hans Holmberg" <Hans.Holmberg@wdc.com>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"jaegeuk@kernel.org" <jaegeuk@kernel.org>,
	"josef@toxicpanda.com" <josef@toxicpanda.com>,
	"Matias Bjørling" <Matias.Bjorling@wdc.com>,
	"Damien Le Moal" <Damien.LeMoal@wdc.com>,
	"Dennis Maisenbacher" <dennis.maisenbacher@wdc.com>,
	"Naohiro Aota" <Naohiro.Aota@wdc.com>,
	"Aravind Ramesh" <Aravind.Ramesh@wdc.com>,
	"Jørgen Hansen" <Jorgen.Hansen@wdc.com>,
	"mcgrof@kernel.org" <mcgrof@kernel.org>,
	"javier@javigon.com" <javier@javigon.com>,
	"hch@lst.de" <hch@lst.de>,
	"a.manzanares@samsung.com" <a.manzanares@samsung.com>,
	"guokuankuan@bytedance.com" <guokuankuan@bytedance.com>,
	"viacheslav.dubeyko@bytedance.com"
	<viacheslav.dubeyko@bytedance.com>,
	"j.granados@samsung.com" <j.granados@samsung.com>
Subject: Re: [LSF/MM/BPF TOPIC]: File system data placement for zoned block devices
Date: Tue, 7 Feb 2023 09:46:46 -0800	[thread overview]
Message-ID: <Y+KOhvnMCyi2NRRZ@zen> (raw)
In-Reply-To: <CANr-nt2q-1GjE6wx4W+6cSV9RULd8PKmS2-qyE2NvhRgMNawXQ@mail.gmail.com>

On Tue, Feb 07, 2023 at 01:31:44PM +0100, Hans Holmberg wrote:
> On Mon, Feb 6, 2023 at 3:24 PM Johannes Thumshirn
> <Johannes.Thumshirn@wdc.com> wrote:
> >
> > On 06.02.23 14:41, Hans Holmberg wrote:
> > > Out of the upstream file systems, btrfs and f2fs supports
> > > the zoned block device model. F2fs supports active data placement
> > > by separating cold from hot data which helps in reducing gc,
> > > but there is room for improvement.
> >
> > FYI, there's a patchset [1] from Boris for btrfs which uses different
> > size classes to further parallelize placement. As of now it leaves out
> > ZNS drives, as this can clash with the MOZ/MAZ limits but once active
> > zone tracking is fully bug free^TM we should look into using these
> > allocator hints for ZNS as well.
> >
> 
> That looks like a great start!
> 
> Via that patch series I also found Josef's fsperf repo [1], which is
> exactly what I have
> been looking for: a set of common tests for file system performance. I hope that
> it can be extended with longer-running tests doing several disk overwrites with
> application-like workloads.

It should be relatively straightforward to add more tests to fsperf and
we are happy to take new workloads! Also, feel free to shoot me any
questions you run into while working on it and I'm happy to help.

> 
> > The hot/cold data can be a 2nd placement hint, of cause, not just the
> > different size classes of an extent.
> 
> Yes. I'll dig into the patches and see if I can figure out how that
> could be done.

FWIW, I was working on reducing fragmentation/streamlining reclaim for
non zoned btrfs. I have another patch set that I am still working on
which attempts to use a working set concept to make placement
lifetime/lifecycle a bigger part of the btrfs allocator.

That patch set tries to make btrfs write faster in parallel, which may
be against what you are going for, that I'm not sure of. Also, I didn't
take advantage of the lifetime hints because I wanted it to help for the
general case, but that could be an interesting direction too!

If you're curious about that work, the current state of the patches is
in this branch:
https://github.com/kdave/btrfs-devel/compare/misc-next...boryas:linux:bg-ws
(Johannes, those are the patches I worked on after you noticed the
allocator being slow with many disks.)

Boris

> 
> Cheers,
> Hans
> 
> [1] https://github.com/josefbacik/fsperf