On Mon, May 13, 2019 at 09:57:43PM +0200, waxhead wrote: > David Sterba wrote: > >On Mon, May 06, 2019 at 05:37:40PM +0300, Timofey Titovets wrote: > >>From: Timofey Titovets <nefelim...@gmail.com> > >> > >>Currently btrfs raid1/10 bаlance requests to mirrors, > >>based on pid % num of mirrors. > >> > > > >Regarding the patches to select mirror policy, that Anand sent, I think > >we first should provide a sane default policy that addresses most > >commong workloads before we offer an interface for users that see the > >need to fiddle with it. > > > As just a regular btrfs user I would just like to add that I earlier > made a comment where I think that btrfs should have the ability to > assign certain DevID's to groups (storage device groups). > > From there I think it would be a good idea to "assign" subvolumes to > either one (or more) group(s) so that btrfs would prefer (if free > space permits) to store data from that subvolume on a certain group > of storage devices. > > If you could also set a weight value for read and write separately > for a group then you are from a humble users point of view good to > go and any PID% optimization (and management) while very interesting > sounds less important. > > As BTRFS scales to more than 32 devices (I think there is a limit > for 30 or 32????) device groups should really be in there from a > management point of view and mount options for readmirror policy > does not sound good the way I understand it as this would affect the > fileystem globally. > > Groups could also allow for useful features like making sure > metadata stays on fast devices, migrating hot data to faster groups > automatically on read, and when (if?) subvolumes support different > storage profiles "Raid1/10/5/6" it sounds like an even better idea > to assign such subvolumes to faster/slower groups depending on the > storage profile. > > Anyway... I just felt like airing some ideas since the readmirror > topic has come up a few times on the mailing list recently.
I did write up a slightly more concrete proposal on how to do this algorithmically (plus quite a lot more) some years ago. I even started implementing it, but I ran into problems of available time and available kernel mad skillz, neither of which I had enough of. https://www.spinics.net/lists/linux-btrfs/msg33916.html Hugo. -- Hugo Mills | Questions are a burden, and answers a prison for hugo@... carfax.org.uk | oneself http://carfax.org.uk/ | PGP: E2AB1DE4 | The Prisoner
signature.asc
Description: Digital signature
