RE: [RFC][PATCH V3] btrfs: ssd_metadata: storing metadata on SSD

From: Paul Jones <paul@pauljones.id.au>
To: "kreijack@inwind.it" <kreijack@inwind.it>,
	Qu Wenruo <quwenruo.btrfs@gmx.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Cc: Michael <mclaud@roznica.com.ua>, Hugo Mills <hugo@carfax.org.uk>,
	Martin Svec <martin.svec@zoner.cz>,
	Wang Yugui <wangyugui@e16-tech.com>
Subject: RE: [RFC][PATCH V3] btrfs: ssd_metadata: storing metadata on SSD
Date: Sat, 30 May 2020 08:57:26 +0000	[thread overview]
Message-ID: <SYBPR01MB4604AB774891E3D172463C5F9E8C0@SYBPR01MB4604.ausprd01.prod.outlook.com> (raw)
In-Reply-To: <de7c16c4-9424-8ccf-16bb-0d3b9d56b6b6@libero.it>

> -----Original Message-----
> From: linux-btrfs-owner@vger.kernel.org <linux-btrfs-
> owner@vger.kernel.org> On Behalf Of Goffredo Baroncelli
> Sent: Saturday, 30 May 2020 4:48 PM
> To: Qu Wenruo <quwenruo.btrfs@gmx.com>; linux-btrfs@vger.kernel.org
> Cc: Michael <mclaud@roznica.com.ua>; Hugo Mills <hugo@carfax.org.uk>;
> Martin Svec <martin.svec@zoner.cz>; Wang Yugui <wangyugui@e16-
> tech.com>
> Subject: Re: [RFC][PATCH V3] btrfs: ssd_metadata: storing metadata on SSD
> 
> On 5/30/20 6:59 AM, Qu Wenruo wrote:
> [...]
> >> This new mode is enabled passing the option ssd_metadata at mount
> time.
> >> This policy of allocation is the "preferred" one. If this doesn't
> >> permit a chunk allocation, the "classic" one is used.
> >
> > One thing to improve here, in fact we can use existing members to
> > restore the device related info:
> > - btrfs_dev_item::seek_speed
> > - btrfs_dev_item::bandwidth (I tend to rename it to IOPS)
> 
> Hi Qu,
> 
> this path was an older version,the current one (sent 2 days ago) store the
> setting of which disks has to be considered as "preferred_metadata".
> >
> > In fact, what you're trying to do is to provide a policy to allocate
> > chunks based on each device performance characteristics.
> >
> > I believe it would be super awesome, but to get it upstream, I guess
> > we would prefer a more flex framework, thus it would be pretty slow to
> merge.
> 
> I agree. And considering that in the near future the SSD will become more
> widespread, I don't know if the effort (and the time required) are worth.

I think it will be. Consider a large 10TB+ filesystem that runs on cheap unbuffered SSDs - Metadata will still be a bottleneck like it is now, just everything happens much faster. Archival storage will likely be rotational based for a long time yet for cost reasons, and this is where ssd metadata shines. I've been running your ssd_metadata patch for over a month now and it's flipping fantastic! The responsiveness it brings to networked archival storage is amazing.

Paul.