linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Karel Zak <kzak@redhat.com>
To: Anand Jain <Anand.Jain@oracle.com>
Cc: linux-btrfs@vger.kernel.org, dsterba@suse.cz
Subject: Re: [PATCH 2/2 v4] btrfs-progs: optimize btrfs_scan_lblkid() for multiple calls
Date: Tue, 11 Nov 2014 12:47:35 +0100	[thread overview]
Message-ID: <20141111114735.GA24268@x2.net.home> (raw)
In-Reply-To: <54536CDA.4090901@oracle.com>

On Fri, Oct 31, 2014 at 07:04:58PM +0800, Anand Jain wrote:
> 
> 
> 
> 
> On 31/10/2014 17:08, Karel Zak wrote:
> >On Fri, Oct 31, 2014 at 12:11:20PM +0800, Anand Jain wrote:
> >>btrfs_scan_lblikd() is called by most the device related command functions.
> >>And btrfs_scan_lblkid() is most expensive function and it becomes more expensive
> >>as number of devices in the system increase. Further some threads call this
> >
> >wouldn't be possible to ask udev rather than scan all devices? I
> >understand than in some cases it's necessary to have robust and
> >independent solution, but for usual use-cases it would be less
> >expensive to read the info from udev where we already keep track about
> >all block devices and where we call libblkid.
> >
> >It would be possible to implement it as optional feature (#ifdev HAVE_LIBUDEV),
> >the library API is very easy to use.
> >
> >(For example lsblk uses libblkid as fallback, the default is udev).
> >
> >     Karel
> >
> >
> 
> I might be missing something, correct me if wrong. Is there any udev API
> which gives me a list of devices which hold btrfs ? I just browsed
> through there isn't any.

 See  udev_enumerate_* API, nice example:
 http://www.signal11.us/oss/udev/

 Anyway, I have sent patches that implement this feature to btrfs-progs. 

 What I see critical is missing ./configure, because it's pretty ugly
 to add hardcoded dependencies (e.g. libudev), there is also no checks
 for another libs, Makefile does not care about place where libs are
 installed, header files,  etc. etc.

 Is there any fundamental problem with autoconf? If no, then I'm ready
 to send patches with some autotools stuff. Comments?

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

  reply	other threads:[~2014-11-11 11:47 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
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 [this message]
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=20141111114735.GA24268@x2.net.home \
    --to=kzak@redhat.com \
    --cc=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).