On 4/2/20 11:33 AM, Steven Davies wrote:
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,
The work done by Anand is very different. He is working to developing better policy about which mirror has to be select during the reading.
I am investigating the possibility to store (reading and *writing*) the metadata in SSD and the data in rotational disk.
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.
There is the "rotational" attribute, which can be set or by the kernel or by appropriate udev rules.
I would therefore vote for configurability of this rather than always choosing SSD over HDD.
As state above, there are two completely different patch set, which address two different problem.
[1] https://patchwork.kernel.org/project/linux-btrfs/list/?series=245121
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
