| Message ID | cover.1657275159.git.anand.jain@oracle.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | device type and create chunk | expand |
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(-) > --
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(-)