From: Josef Bacik <josef@toxicpanda.com>
To: Goffredo Baroncelli <kreijack@inwind.it>
Cc: linux-btrfs@vger.kernel.org,
Zygo Blaxell <ce3g8jdj@umail.furryterror.org>,
David Sterba <dsterba@suse.cz>,
Sinnamohideen Shafeeq <shafeeqs@panasas.com>,
Paul Jones <paul@pauljones.id.au>, Boris Burkov <boris@bur.io>
Subject: Re: [PATCH 0/7][V11] btrfs: allocation_hint
Date: Tue, 1 Mar 2022 16:43:38 -0500 [thread overview]
Message-ID: <Yh6Tit2dKcLt7xJP@localhost.localdomain> (raw)
In-Reply-To: <e8d1a33a-a75a-1a25-b788-a2da5019e6c4@inwind.it>
On Tue, Mar 01, 2022 at 07:55:07PM +0100, Goffredo Baroncelli wrote:
> On 01/03/2022 16.07, Josef Bacik wrote:
> > On Mon, Feb 28, 2022 at 10:01:35PM +0100, Goffredo Baroncelli wrote:
> > > Hi Josef,
> > >
> > > On 28/02/2022 18.04, Josef Bacik wrote:
> > > > On Wed, Jan 26, 2022 at 09:32:07PM +0100, Goffredo Baroncelli wrote:
> > > > > From: Goffredo Baroncelli <kreijack@inwind.it>
> > > > >
> > > > > Hi all,
> > > > >
> > > [...
> > >
> > > > > In V11 I added a new 'feature' file /sys/fs/btrfs/features/allocation_hint
> > > > > to help the detection of the allocation_hint feature.
> > > > >
> > > >
> > > > Sorry Goffredo I dropped the ball on this, lets try and get this shit nailed
> > > > down and done so we can get it merged. The code overall looks good, I just have
> > > > two things I want changed
> > > >
> > > > 1. The sysfs file should use a string, not a magic number. Think how
> > > > /sys/block/<dev>/queue/scheduler works. You echo "metadata_only" >
> > > > allocation_hint, you cat allocation_hint and it says "none" or
> > > > "metadata_only". If you want to be fancy you can do exactly like
> > > > queue/scheduler and show the list of options with [] around the selected
> > > > option.
> > >
> > > Ok.
> > > >
> > > > 2. I hate the major_minor thing, can you do similar to what we do for devices/
> > > > and symlink the correct device sysfs directory under devid?
> > > >
> > > Ok, do you have any suggestion for the name ? what about bdev ?
> > >
> >
> > You literally just add a link to the device kobj to the devid kobj. If you look
> > at btrfs_sysfs_add_device(), you would do something like this (completely
> > untested and uncompiled)
>
> I will give an eye to your code; thanks. However my question was more basic.
>
> Now we have:
>
> .../btrfs/<uuid>/devinfo/<dev-nr>/major_minor
>
> with the link, as you suggested, I think that we will have:
>
> .../btrfs/<uuid>/devinfo/<dev-nr>/bdev -> ../../../../devices/pci0000:00/0000:00:01.2/0000:01:00.1/ata6/host5/target5:0:0/5:0:0:0/block/sdg/sdg3
> ^^^^
>
> (notice 'bdev', which is the name that I asked)
>
> looking at your patch, it seems to me that the link will be named like the device name:
>
> .../btrfs/<uuid>/devinfo/<dev-nr>/sdg3 -> ../../../../devices/pci0000:00/0000:00:01.2/0000:01:00.1/ata6/host5/target5:0:0/5:0:0:0/block/sdg/sdg3
> ^^^^
>
> which is quite convoluted as approach, because the code has to find a name that matches a device (sdg3), instead to look for a fixed name (bdev).
>
> Because I know that every people has a strong, valid (and above all different !) opinion about the name, I want to ask it before issue another patches set.
> For the record, I like 'bdev' only because I saw used (by bcache)
>
> IMHO, the btrfs world had been simpler if devices/ sysfs directory was populated by the btrfs-dev-nr instead the device name
>
Ahh ok I see, you make a good point. I agree it would have been better to have
the dev nrs in devices and then links in there, but here we are.
I think for now drop this patch from this series, since it's another bike
shedding opportunity and I'd rather get the core functionality in. Do what I
asked in #1 and drop this patch from this series, follow up with a different
series if you feel strongly enough about it and that way we can have that
discussion in that thread and not hold up your feature. Thanks,
Josef
next prev parent reply other threads:[~2022-03-01 21:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-26 20:32 [PATCH 0/7][V11] btrfs: allocation_hint Goffredo Baroncelli
2022-01-26 20:32 ` [PATCH 1/7] btrfs: add flags to give an hint to the chunk allocator Goffredo Baroncelli
2022-01-26 20:32 ` [PATCH 2/7] btrfs: export the device allocation_hint property in sysfs Goffredo Baroncelli
2022-01-26 20:32 ` [PATCH 3/7] btrfs: change the device allocation_hint property via sysfs Goffredo Baroncelli
2022-01-26 20:32 ` [PATCH 4/7] btrfs: add allocation_hint mode Goffredo Baroncelli
2022-01-26 20:32 ` [PATCH 5/7] btrfs: rename dev_item->type to dev_item->flags Goffredo Baroncelli
2022-01-26 20:32 ` [PATCH 6/7] btrfs: add major and minor to sysfs Goffredo Baroncelli
2022-01-26 20:32 ` [PATCH 7/7] Add /sys/fs/btrfs/features/allocation_hint Goffredo Baroncelli
2022-02-15 18:49 ` [PATCH 0/7][V11] btrfs: allocation_hint Goffredo Baroncelli
2022-02-16 0:22 ` Qu Wenruo
2022-02-16 3:28 ` Zygo Blaxell
2022-02-16 4:43 ` Paul Jones
2022-02-25 20:18 ` Boris Burkov
2022-02-28 17:04 ` Josef Bacik
2022-02-28 21:01 ` Goffredo Baroncelli
2022-03-01 15:07 ` Josef Bacik
2022-03-01 18:55 ` Goffredo Baroncelli
2022-03-01 21:43 ` Josef Bacik [this message]
2022-03-02 19:30 ` Goffredo Baroncelli
2022-03-02 21:23 ` Josef Bacik
2022-03-03 19:01 ` Goffredo Baroncelli
2022-03-04 14:56 ` Josef Bacik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yh6Tit2dKcLt7xJP@localhost.localdomain \
--to=josef@toxicpanda.com \
--cc=boris@bur.io \
--cc=ce3g8jdj@umail.furryterror.org \
--cc=dsterba@suse.cz \
--cc=kreijack@inwind.it \
--cc=linux-btrfs@vger.kernel.org \
--cc=paul@pauljones.id.au \
--cc=shafeeqs@panasas.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox