RE: [PATCH 0/7][V11] btrfs: allocation_hint

From: Paul Jones <paul@pauljones.id.au>
To: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>,
	Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: "kreijack@inwind.it" <kreijack@inwind.it>,
	Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.cz>,
	Sinnamohideen Shafeeq <shafeeqs@panasas.com>,
	Boris Burkov <boris@bur.io>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: RE: [PATCH 0/7][V11] btrfs: allocation_hint
Date: Wed, 16 Feb 2022 04:43:43 +0000	[thread overview]
Message-ID: <SYXPR01MB191845786070C7B5E9A67F8D9E359@SYXPR01MB1918.ausprd01.prod.outlook.com> (raw)
In-Reply-To: <YgxvUC86zumH3OF1@hungrycats.org>

> -----Original Message-----
> From: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
> Sent: Wednesday, 16 February 2022 2:28 PM
> To: Qu Wenruo <quwenruo.btrfs@gmx.com>
> Cc: kreijack@inwind.it; Josef Bacik <josef@toxicpanda.com>; David Sterba
> <dsterba@suse.cz>; Sinnamohideen Shafeeq <shafeeqs@panasas.com>;
> Paul Jones <paul@pauljones.id.au>; Boris Burkov <boris@bur.io>; linux-
> btrfs@vger.kernel.org
> Subject: Re: [PATCH 0/7][V11] btrfs: allocation_hint
> 
> On Wed, Feb 16, 2022 at 08:22:55AM +0800, Qu Wenruo wrote:
> >
> >
> > On 2022/2/16 02:49, Goffredo Baroncelli wrote:
> > > Hi Josef,
> > >
> > > gentle ping...
> > >
> > > few months ago you showed some interest in this patches set. Few of
> > > the cc-ed person use this patch set.
> > >
> > > I know that David showed some interest in the Anand approach (i.e.
> > > no knobs, but an automatic behavior looking at the speed of the devices).
> > >
> > > At the time when I tried this approach in the first attempts, I got
> > > the complain that the kernel may not know the performance
> > > differences of the disk (HDD vs SSD vs NVME vs ZONED disk...).
> >
> > Sorry I didn't check the patches in details.
> >
> > But I'm a little concerned about how to accurately determine the
> > performance of a device.
> >
> > If doing it automatically, there must be some (commonly very short)
> > time spent to do the test.
> >
> > In the very short time, I doubt we can even accurately got a full
> > picture of a device (from sequential read/write speed to IOPS values)
> >
> > For spinning disks, the sequential read/write speed even change based
> > on their LBA address (as their physical location inside the plate can
> > change their linear velocity, since the angular velocity is fixed).
> >
> > And even for SSD, IOPS can var dramatically due to cache/controller
> > difference.
> >
> >
> > For a proper performance aware setup, I guess the only correct way to
> > fetch performance characteristics is from the (advanced) user.
> >
> > Or we may need to spent at least tens of minutes to do proper tests to
> > get the result.
> >
> > For regular end users, the difference between SSD and HDD is huge
> > enough and simply preferring SSD for metadata is good enough.
> >
> > But for more complex setup, like btrfs over LUKS over LVM (even
> > crosses several physical devices), I doubt if it's even possible to
> > fetch the correct performance characteristics automatically.
> 
> I agree with all of the above.
> 
> An automatic performance detection/configuration daemon can easily set
> the metadata/data preference bits during mkfs, or monitor the system's
> iostats and change preferences over time if this is really useful and desired.
> It doesn't have to run in the kernel.

At the moment it's all manual anyway so a bit of a moot point until something is merged.
I've been using this patchset since the beginning and imho it's killer feature is being able to split data and metadata onto different speed devices. It massively speeds up large filesystems that are metadata heavy.

Paul.