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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: linux-btrfs-owner@xxxxxxxxxxxxxxx <linux-btrfs-
> owner@xxxxxxxxxxxxxxx> On Behalf Of Goffredo Baroncelli
> Sent: Monday, 6 April 2020 5:04 AM
> To: Achim Gratz <Stromeko@xxxxxxxx>; linux-btrfs@xxxxxxxxxxxxxxx
> Subject: Re: [RFC][PATCH v2] btrfs: ssd_metadata: storing metadata on SSD
> 
> On 4/5/20 10:22 AM, Achim Gratz wrote:
> > Goffredo Baroncelli writes:
> >> This is an RFC; I wrote this patch because I find the idea
> >> interesting even though it adds more complication to the chunk allocator.
> >>
> >> The core idea is to store the metadata on the ssd and to leave the
> >> data on the rotational disks. BTRFS looks at the rotational flags to
> >> understand the kind of disks.
> >
> > My comment really is only about his aspect of your proposal: I would
> > consider a more general way of introducing a tiering of disks so that
> > one can discern between slower and faster SSD as well.
> 
> This is a further step. I didn't mind to a tiering of fast (NVM ?) and slow SSD.
> For that there are some unused fields in the superblock which can be used.
> 
> However now my first concern is if this is
> a) really useful
> b) I introduced some functional regression
> 
> Regarding a), there is an increment of performance; however stacking btrfs
> over bcache leads to an even bigger gain; of course stacking btrfs over
> bcache complicates the configuration for the raid setup
> 
> Regarding b) the only regression that I found is that the logic behind the
> allocation of disks in RAID5/RAID6 became more complex. But I am not sure if
> this can be called regression.

This is definitely useful for me. I've been meaning to implement it for ages, but was a bit afraid to try as kernel development is not my area.
I've also been thinking about trying bcache, but I remember hearing about people having corruption issues when used with btrfs. That was a while ago, so I presume they are fixed now.
Crazy idea - is there a way btrfs could hook into bcache or dm-cache directly? I know that's a layering violation, but btrfs doesn't use the normal layering paradigm anyway.

Paul.




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux