02.04.2020 12:33, Steven Davies пишет:
On 01/04/2020 21:03, Goffredo Baroncelli wrote:
From: Goffredo Baroncelli <kreijack@xxxxxxxxx>
When this mode is enabled, the allocation policy of the chunk
is so modified:
- when a metadata chunk is allocated, priority is given to
ssd disk.
- When a data chunk is allocated, priority is given to a
rotational disk.
When a striped profile is involved (like RAID0,5,6), the logic
is a bit more complex. If there are enough disks, the data profiles
are stored on the rotational disks only; the metadata profiles
are stored on the non rotational disk only.
If the disks are not enough, then the profiles is stored on all
the disks.
Example: assuming that sda, sdb, sdc are ssd disks, and sde, sdf are
rotational ones.
A data profile raid5, will be stored on sda, sdb, sdc, sde, sdf (sde
and sdf are not enough to host a raid5 profile).
A metadata profile raid5, will be stored on sda, sdb, sdc (these
are enough to host a raid5 profile).
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 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
--
С уважением, Михаил
067-786-11-75
