On 4/3/20 6:28 PM, Hugo Mills wrote: > On Fri, Apr 03, 2020 at 06:19:59PM +0200, Goffredo Baroncelli wrote: >> On 4/3/20 10:43 AM, Michael wrote: >>> 02.04.2020 12:33, Steven Davies пишет: >>>> On 01/04/2020 21:03, Goffredo Baroncelli wrote: >>>>> From: Goffredo Baroncelli <kreijack@xxxxxxxxx> >> [...] >>>>> To enable this mode pass -o ssd_metadata at mount time. >>>>> >>>>> Signed-off-by: Goffredo Baroncelli <kreijack@xxxxxxxxx> >>>> >>>> The idea of this sounds similar to what Anand has been working on with the readmirror patchset[1] which was originally designed to prefer reading from SSD devices in a RAID1 configuration but has evolved into allowing the read policy to be configured through sysfs, at least partly because detecting SSDs correctly is not an exact science. Also, there may be more considerations than just HDD or SSD: for example in my system I use a SATA SSD and an NVMe SSD in RAID1 where the NVMe device is twice the speed of the SSD. >>> May be something like -o metadata_preferred_devices=device_id,[device_id,[device_id]]... ? >> >> I think that it should be a device property instead of a device list passed at mount time. >> Looking at the btrfs_dev_item structure (which is embedded in the super block), there are several promising fields: >> - seek_speed >> - bandwidth >> - dev_group >> >> currently these fields are unused. > > The first two of these at least were left over from the last > attempt at this which got anywhere near code. > > If you're going to do this kind of thing, please read (at least) my > (sadly code-less; sorry) proposal from a few years ago: > > https://www.mail-archive.com/linux-btrfs@xxxxxxxxxxxxxxx/msg33632.html > > Essentially, allowing for multiple policies for chunk allocation, > of which this case is a small subset. > > I'd envisaged putting the relevant config data into properties, but > since we didn't actually have them in any sense at the time, I got > bogged down in that part of it. Ideas about properties: https://github.com/kdave/drafts/blob/master/btrfs/properties.txt >> Se we are free to use as we wish. For example, if we use 2 bit of dev_group as marker >> for "not for metadata" and "not for date" we can have the following combination: >> - 0 (default) -> the disk is suitable for both data and metadata >> - "not for metadata" -> the disk has an high priority for "data" >> - "not for data" -> the disk has an high priority for "metadata" >> - "not for data" and "not for metadata" -> invalid >> >> As kernel<->user space interface, I like the idea to export these bits via sysfs.. unfortunately there is no a directory for the devices.... :-( >> >> >>>> >>>> I would therefore vote for configurability of this rather than always choosing SSD over HDD. >>>> >>>> [1] https://patchwork.kernel.org/project/linux-btrfs/list/?series=245121 >>>> >>> >> >> >
