From: Benny Halevy <bhalevy@panasas.com>
To: Jim Rees <rees@umich.edu>
Cc: Steve Dickson <SteveD@redhat.com>,
linux-nfs@vger.kernel.org, sfaibish <sfaibish@emc.com>,
peter honeyman <honey@citi.umich.edu>
Subject: Re: [PATCH 0/4] nfs-utils: rework device scanning in blkmapd
Date: Mon, 11 Oct 2010 11:05:56 -0400 [thread overview]
Message-ID: <4CB327D4.8050807@panasas.com> (raw)
In-Reply-To: <cover.1286552019.git.rees@umich.edu>
Merged, thanks!
Benny
On 2010-10-08 12:06, Jim Rees wrote:
> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2010-10-11 15:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-08 16:06 [PATCH 0/4] nfs-utils: rework device scanning in blkmapd Jim Rees
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 ` Benny Halevy [this message]
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=4CB327D4.8050807@panasas.com \
--to=bhalevy@panasas.com \
--cc=SteveD@redhat.com \
--cc=honey@citi.umich.edu \
--cc=linux-nfs@vger.kernel.org \
--cc=rees@umich.edu \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.