linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jim Rees <rees@umich.edu>
To: Steve Dickson <SteveD@redhat.com>
Cc: linux-nfs@vger.kernel.org, sfaibish <sfaibish@emc.com>,
	peter honeyman <honey@citi.umich.edu>
Subject: [PATCH 0/4] nfs-utils: rework device scanning in blkmapd
Date: Fri, 8 Oct 2010 12:06:33 -0400	[thread overview]
Message-ID: <cover.1286552019.git.rees@umich.edu> (raw)

This series reworks the way device scanning is done in blkmapd as a result
of test results and discussions at the Fall 2010 Bakeathon.

We get rid of the config file and instead examine all block devices as
listed in /sys/block and /proc/partitions (this is the way fdisk does it).
Since we're looking for pnfs signatures, it usually doesn't hurt to examine
a device that isn't part of a layout, and in general it's hard to tell ahead
of time which devices should be considered, so I think having a config file
does more harm than good.

We get rid of periodic (once a minute) device rescanning, and instead rescan
only when the kernel asks for a layout.  This will suffice for the common
case, and works with all current known server implementations.  A later
patch will re-introduce rescanning during the life of a layout, but will be
triggered by configuration change notifications from udev, rather than by
expiration of an arbitrary time interval.

We get rid of the test for active/passive devices.  This test really only
works for EMC servers, and isn't even needed because the passive devices
will be skipped over during signature detection.  Just remove the detection
code.

Jim Rees (4):
  blkmapd: get rid of config file and instead examine all block devices
  blkmapd: don't rescan periodically
  blkmapd: don't use atomicio() where it's not needed
  blkmapd: don't try to distinguish between active/passive devices

 utils/blkmapd/Makefile.am        |    2 -
 utils/blkmapd/cfg.c              |  248 --------------------------------------
 utils/blkmapd/cfg.h              |   47 -------
 utils/blkmapd/device-discovery.c |  141 ++++++++--------------
 utils/blkmapd/device-discovery.h |    3 -
 utils/blkmapd/device-inq.c       |   40 ++-----
 utils/blkmapd/device-process.c   |    2 +-
 7 files changed, 60 insertions(+), 423 deletions(-)
 delete mode 100644 utils/blkmapd/cfg.c
 delete mode 100644 utils/blkmapd/cfg.h


             reply	other threads:[~2010-10-08 16:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-08 16:06 Jim Rees [this message]
2010-10-08 16:07 ` [PATCH 1/4] blkmapd: get rid of config file and instead examine all block devices Jim Rees
2010-10-08 16:07 ` [PATCH 2/4] blkmapd: don't rescan periodically Jim Rees
2010-10-08 16:08 ` [PATCH 3/4] blkmapd: don't use atomicio() where it's not needed Jim Rees
2010-10-08 16:09 ` [PATCH 4/4] blkmapd: don't try to distinguish between active/passive devices Jim Rees
2010-10-11 15:05 ` [PATCH 0/4] nfs-utils: rework device scanning in blkmapd Benny Halevy

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=cover.1286552019.git.rees@umich.edu \
    --to=rees@umich.edu \
    --cc=SteveD@redhat.com \
    --cc=honey@citi.umich.edu \
    --cc=linux-nfs@vger.kernel.org \
    --cc=sfaibish@emc.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;
as well as URLs for NNTP newsgroup(s).