Re: Metadata chunks on ssd?

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

 





Le 24 décembre 2019 03:04:34 Wang Shilong <wangshilong1991@xxxxxxxxx> a écrit :

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.

If you happen to still have a couple patches around (even if they dont apply cleanly), I'm interested!


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.

My first idea was a preference to be set by the admin himself actually. A tristate that would be set for data chunks and for metadata chunks, for each device. Something like:

- "never": never allocate this type of chunk on this device
- "default": keep the current allocator behavior
- "always": consider this device first when trying to allocate

The allocator would then run in 2 passes max, like this:

- try to allocate considering only the device tagged "always"
- if this fails, try to allocate considering the devices tagged "always" and "default"

For my setup, I would use 2 small SSDs set to metadata=always data=never, and the other rotational drives set to metadata=default data=default.

If we want to autodetect things while not being too invasive, on fs creation and on device add/replace, we could autodetect the rotational status, and maybe set data=default metadata=always for non-rotational drives, and data=default metadata=default for the others. This would enhance the overall experience without getting the user potential "out of space" issues he wouldn't expect.

Migration from a previous preference-unaware code would see all the prefs set to "default", without adding a incompat flag as being preference-unaware doesn't break the filesystem.

--
Stéphane.





[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