Steven Davies wrote:
On 2019-03-19 10:00, Anand Jain wrote:
RFC patch as of now, appreciate your comments. This patch set has
been tested.
....
This patch introduces a framework so that we can add more policies, and
converts the existing %pid into as a configurable parameter using the
property. And also provides a transient readmirror mount option, so that
this property can be applied for the read io during mount and for
readonly FS.
Is it possible to set this property at mkfs time?
For example:
btrfs property set <mnt> readmirror pid
btrfs property set <mnt> readmirror ""
btrfs property set <mnt> readmirror devid<n>
mount -o readmirror=pid <mnt>
mount -o readmirror=devid<n> <mnt>
This is an edge case but should we be allowed to set more than one
device as a read mirror in a 3+ device array? In theory there could be
two fast disks and one slow disk where all stripes are guaranteed to be
on at least one fast disk.
I'll test these patches out when I have some spare time over the next
few weeks. Do you have a tree I can pull / what are the patches based on?
Way beyond this patch series, considering a 3+ device raid1 array with
mixed fast and slow disks perhaps there could also be a write preference
for disks to fill up the fast disks first.
Steven Davies
This is more of less a feature request , but it feels right to mention
this here...
If I remember correctly BTRFS does not currently scale to more than 32
devices right now (due to some striping related stuff), but if BTRFS can
have many more devices, and even now at >16 devices would it not make
sense to be able to "tag" devices or make "device groups".
For example - when (if) subvolumes can have different "RAID" profiles it
would perhaps make sense to ensure that certain subvolumes would prefer
to use storage from a certain group of devices. In a mixed setup where
you have both SSD's, HDD's and those new M2 things (or whatever) it
could be nice to make a subvolume for /usr or /var and ask BTRFS to
prefer to store that on a SSD's while a subvolume for /home could be
preferred to be stored on HDD's.
Having device groups could also allow to define certain storage devices
for "hot data" so that data that is read often could auto-migrate to the
faster storage devices.. As I understand BTRFS it is "just" a matter of
setting a flag pr. chunk so it would prefer to be allocated on device of
type/group xyz...
In a N-way mirror setup you could would read mostly from SSD's while
using HDD's for storing the mirror copy.
if I may suggest ... I think something along the lines of...
'btrfs device setgroup DEVID GROUPNAME'
'btrfs property set GROUPNAME readweight=100, writeweight=50'
'btrfs property set GROUPNAME readmirror=whatever_policy'
and
'btrfs subvolume setgroup GROUPNAME'
would to just fine...
Again , just a suggestion from a regular BTRFS user. Nothing more , but
please consider something like this. The current readmirror idea sounds
a tad limited as it does not account for subvolumes.
