Re: Metadata chunks on ssd?

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

 



On 2019-12-23 21:04, Wang Shilong wrote:
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.
This doesn't tell you that the device is an SSD though, just that it reports to the kernel as non+rotational. For example, NBD devices present as non-rotational by default, and in most cases you do _not_ want hot data on a network disc.

The important thing here is disk performance, not whether it's an SSD or not. An SD card is non-rotational and solid-state, but on most systems the performance is going to be sufficiently bad for BTRFS-type workloads that it's almost useless for this type of thing.

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





[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