linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anand Jain <Anand.Jain@oracle.com>
To: dsterba@suse.cz, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 2/2 v2] btrfs-progs: optimize btrfs_scan_lblkid() for multiple calls
Date: Fri, 31 Oct 2014 09:38:25 +0800	[thread overview]
Message-ID: <5452E811.1080001@oracle.com> (raw)
In-Reply-To: <20141030141833.GA15771@twin.jikos.cz>


Hi David,

  Thanks for the review..


On 30/10/2014 22:18, David Sterba wrote:
> On Thu, Oct 23, 2014 at 02:30:08PM +0800, Anand Jain wrote:
>>    introduce a global variable scan_done, which is set when scan is
>>    done succssfully per thread. So that following calls to this function
>>    will just return success.
>
> The rest is good, I'm a bit concerned about the global variable. It
> sholud be at least declared static and not visible outside of utils.c.

oh yes.

> The function btrfs_scan_lblkid is called indirectly from various
> callchains. For a moment I was thinking about declaring a variable to
> hold the scanning status, but btrfs_scan_lblkid is not always called
> from a scope of one cmd_something function. Eg. from btrfs_scan_fs_devices
> that in turn is called from several other functions. As we're not
> concerned about multi-threading, we can use the global variable.

yes. initially I was thinking the threads which needs the btrfs
device list would do something like init_device_list in the beginning
of the thread. And  the init device_list has to be created in
collaboration with the kernel, progs should take the mounted device
list from the kernel and read the unmounted devices only.
So I had the proposal of either

btrfs: introduce procfs interface for the device list
OR
btrfs: introduce BTRFS_IOC_GET_DEVS

but most suggest sysfs. sysfs is a state-full it does not suite the
purpose. previously we had sysfs bugs when device change its state.
we don't have that issue with profs/ioctl.

anyway for now I think btrfs_scan_done provides a simple workaround
fix as we don't have multi thread with in a process.

the other proposal I was thinking to make any device related operation
only thru the kernel, for example 'btrfs dev scan' will be only command
which will scan the system for the btrfs devices and register them with
the kernel (exclude the maintenance commands like btrfs check for now,
or move them into the kernel in the long run). And all further device
reporting will be from the kernel. With this progs can be very sleek..


>>    Further if any function needs to force scan after scan_done is set,
>>    then it can be done when there is such a requirement, but as of now there
>>    isn't any such requirement.
>
> Right, then we could introduce something like btrfs_scan_reset_status
> and then btrfs_scan_lblkid would work as usual.

Sent out V3 with this changes, Thanks.

>> --- a/utils.c
>> +++ b/utils.c
>> @@ -52,6 +52,8 @@
>>   #define BLKDISCARD	_IO(0x12,119)
>>   #endif
>>
>> +int scan_done = 0;
>
> I'll change it to the following and add to integration.
>
> int btrfs_scan_done = 0;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

  reply	other threads:[~2014-10-31  1:38 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-15  0:51 [PATCH 1/2] btrfs-progs: introduce btrfs_register_all_device() Anand Jain
2014-10-15  0:51 ` [PATCH 2/2] btrfs-progs: optimize btrfs_scan_lblkid() for multiple calls Anand Jain
2014-10-23  6:30   ` [PATCH 2/2 v2] " Anand Jain
2014-10-30 14:18     ` David Sterba
2014-10-31  1:38       ` Anand Jain [this message]
2014-10-31  3:19   ` [PATCH 2/2 v3] " Anand Jain
2014-10-30 14:33 ` [PATCH 1/2] btrfs-progs: introduce btrfs_register_all_device() David Sterba
2014-10-31  2:28   ` Anand Jain
2014-10-31  4:11 ` [PATCH 1/2 v4] " Anand Jain
2014-10-31  4:11   ` [PATCH 2/2 v4] btrfs-progs: optimize btrfs_scan_lblkid() for multiple calls Anand Jain
2014-10-31  9:08     ` Karel Zak
2014-10-31 11:04       ` Anand Jain
2014-11-11 11:47         ` Karel Zak
2014-11-14 16:51           ` David Sterba
2014-11-28  9:33             ` Karel Zak

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=5452E811.1080001@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).