On Tue, Dec 24, 2019 at 7:38 AM Hans van Kranenburg <hans@xxxxxxxxxxx> wrote:
>
> Hi Stéphane,
>
> On 12/23/19 2:44 PM, Stéphane Lesimple wrote:
> >
> > Has this ever been considered to implement a feature so that metadata
> > chunks would always be allocated on a given set of disks part of the btrfs
> > filesystem?
>
> Yes, many times.
>
I implement it locally before for my local testing before.
> > As metadata use can be intensive and some operations are known to be slow
> > (such as backref walking), I'm under the (maybe wrong) impression that
> > having a set of small ssd's just for the metadata would give quite a boost
> > to a filesystem. Maybe even make qgroups more usable with volumes having 10
> > snapshots?
>
> No, it's not wrong. For bigger filesystems this would certainly help.
>
> > This could just be a preference set on the allocator,
>
> Yes. Now, the big question is, how do we 'just' set this preference?
>
> Be sure to take into account that the filesystem has no way to find out
> itself which disks are those ssds. There's no easy way to discover this
> in a running system.
>
No, there is API for filesystem to detect whether lower device is SSD or not.
Something like:
if (!blk_queue_nonrot(q))
fs_devices->rotating = 1;
Currently, btrfs will treat filesystem as rotational disks if any of
one disk is rotational,
We might record how many non-rotational disks, and make chunk allocation try SSD
firstly if it possible.
> > so that a 6 disks
> > raid1 FS with 4 spinning disks and 2 ssds prefer to allocate metadata on
> > the ssd than on the slow drives (and falling back to spinning disks if ssds
> > are full, with the possibility to rebalance later).
> >
> > Would such a feature make sense?
>
> Absolutely.
>
> Hans
>
