> -----Original Message----- > From: linux-btrfs-owner@xxxxxxxxxxxxxxx <linux-btrfs- > owner@xxxxxxxxxxxxxxx> On Behalf Of Goffredo Baroncelli > Sent: Saturday, 30 May 2020 4:48 PM > To: Qu Wenruo <quwenruo.btrfs@xxxxxxx>; linux-btrfs@xxxxxxxxxxxxxxx > Cc: Michael <mclaud@xxxxxxxxxxxxxx>; Hugo Mills <hugo@xxxxxxxxxxxxx>; > Martin Svec <martin.svec@xxxxxxxx>; 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.
