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

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

[Anand Jain]

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.

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.

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(-)

-- 
2.33.1

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

[Lukas Straub]

[-- 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 --]