Re: [PATCH 0/2 v2 RFC] device type and create chunk

[Lukas Straub <lukasstraub2@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2030 bytes --]

On Mon, 11 Jul 2022 19:14:50 +0800
Anand Jain <anand.jain@oracle.com> wrote:

> v2: Arrange devices by type and then by free space. Split device type and
>      its latency into an enum array. (Kdave)
>     Marked RFC to obtain more feedback.
> 
> v1: https://lore.kernel.org/linux-btrfs/cover.1642518245.git.anand.jain@oracle.com/t/
> 
> -------- original cover letter -----
> 
> I had these patches as part of experiments with the readpolicy I am
> sending it now. This is different from the allocation_hint mode patch-set
> where I use the device type to make the allocation destination automatic.

IMHO this auto-detection is not worth it. Everyone else (lvmcache, bcache,
dm-writecache, etc.) has the user specify manually which devices is the
faster one and if you set up a new storage array you'll have to think
about this anyway.

I'd like for btrfs to be boring and not differ from other
implementations if possible.

> Patch 1/2 keeps the device's type in the struct btrfs_device so that we
> could maintain the status if there are mixed devices in the
> filesystem.
> 
> And if so, then patch 2/2 shall take care of arranging the disks by the
> order of latency so that metadata chunks can pick disk with low latency
> and data can pick the disk with higher latency.
> 
> By having fewer restrictions and not hard coding the chunk allocation
> destination helps to cause the spillover to the available disk space
> instead of causing the spurious ENOSPC.

If we only let the user set allocation _hints_ (e.g. prefer this device
over that) that won't be a problem.

Regards,
Lukas Straub

> Anand Jain (2):
>   btrfs: keep device type in the struct btrfs_device
>   btrfs: create chunk device type latency aware
> 
>  fs/btrfs/dev-replace.c |   1 +
>  fs/btrfs/disk-io.c     |   2 +
>  fs/btrfs/volumes.c     | 109 +++++++++++++++++++++++++++++++++++++++--
>  fs/btrfs/volumes.h     |  24 ++++++++-
>  4 files changed, 129 insertions(+), 7 deletions(-)
> 



-- 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]