<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.linux.kernel.device-mapper.devel">
    <title>gmane.linux.kernel.device-mapper.devel</title>
    <link>http://blog.gmane.org/gmane.linux.kernel.device-mapper.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15973"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15958"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15928"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15907"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15906"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15903"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15902"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15900"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15892"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15863"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15845"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15842"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15841"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15837"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15791"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15790"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15783"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15779"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15771"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15765"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15973">
    <title>[PATCH v3 00/16] Block cleanups</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15973</link>
    <description>&lt;pre&gt;Incorporated various review feedback, and I reordered/reworked the patches to
make them more coherent.

This also has the latest version of the closure code, incorporating review
feedback from Joe and Tejun. I may rewrite the bio splitting stuff to not
depend on it so it can go in sooner (Tejun is not a fan of closures), but IMO
the patch is better for using them.

First 5 patches: Kill bi_destructor

Next 3 patches: Better bio splitting

Next 3 patches: Rework bio cloning to not clone entire bio vec

Tejun also pointed out that with the bio splitting improvements we ought to be
able to get rid of merge_bvec_fn, so I started on that. Those patches are
definitely a WIP, though.

For most of the md code, it looks like things will almost just work - they
already had bio_pair_split() calls to handle single page bios that crossed bvec
boundries, but bio_pair_split() now splits arbitrary bios so things should just work.

(I just thought of one problem - previously, in practice you'd never need to
split a bio more &lt;/pre&gt;</description>
    <dc:creator>Kent Overstreet</dc:creator>
    <dc:date>2012-05-25T20:25:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15958">
    <title>[PATCH 0/2] multipath: compile cleanup</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15958</link>
    <description>&lt;pre&gt;When the multipath code is compiled with the standard redhat rpm cflags,
there are a number of warnings that get issued, some about real problems.

These patches switch multipath to use those cflags, and then clean up
warnings. If people want upstream to continue using the existing cflags,
I don't particularly mind.  I really included the first patch to make sure
people can see the warnings that the second patch corrects.

Also, some of the warnings are for actual errors, and how to fix them is
obvious.  Others won't actually cause problems, and if people object to
the changes I made to make them go away, I'm happy to fix them differently. 

Benjamin Marzinski (2):
  multipath: Build with standard rpm cflags
  multipath: Fix warnings from stricter compile options.

 Makefile.inc                     |    6 +++++-
 libmpathpersist/mpath_persist.c  |   10 +++++++---
 libmpathpersist/mpath_pr_ioctl.c |    9 +++++++++
 libmultipath/alias.c             |    8 ++++++--
 mpathpersist/main.c              |    2 --
 m&lt;/pre&gt;</description>
    <dc:creator>Benjamin Marzinski</dc:creator>
    <dc:date>2012-05-25T04:57:41</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15928">
    <title>bcache performance test problem</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15928</link>
    <description>&lt;pre&gt;Hi Kent,

I have tested bcache on my platform, but the result is not good. I think maybe the wrong config caused it. Would you pls help me to check the config, or give me some advice for bcache performance testing?

My SSD card is  a PCIe SSD card (about 120,000 IOPS), and I used 10GB.

I have download the code from git://evilpiepirate.org/~kent/linux-bcache.git.
The commands creating bcache is below:
make-bcache -B /dev/sdb8
make-bcache -C -w4k -b1M -writeback /dev/hioa5

I use FIO to test the seq./random IO performance, and the result is below:
write             read                    randwrite    randread
bcache               10809 KB/s    164502.5 KB/s     2713 KB/s    29640 KB/s
cache_hit_rate  80                  79                         94                92


And the basic test result is:
Write                   read                  randwrite             randread
HDD      81211.6 KB/s       172242 KB/s     2606 KB/s             1855 KB/s
SSD       250948.2 KB/s     813855 KB/s     238892.7 KB/s   &lt;/pre&gt;</description>
    <dc:creator>Qinling</dc:creator>
    <dc:date>2012-05-24T01:14:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15907">
    <title>[PATCH] multipath: Some device configuration changes forNetAppLUNs</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15907</link>
    <description>&lt;pre&gt;NetApp has asked for these configuration changes.

Signed-off-by: Benjamin Marzinski &amp;lt;bmarzins&amp;lt; at &amp;gt;redhat.com&amp;gt;
---
 libmultipath/hwtable.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: multipath-tools-120518/libmultipath/hwtable.c
===================================================================
--- multipath-tools-120518.orig/libmultipath/hwtable.c
+++ multipath-tools-120518/libmultipath/hwtable.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -912,11 +912,12 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static struct hwentry default_hw[] = {
 {
 .vendor        = "NETAPP",
 .product       = "LUN.*",
-.features      = "1 queue_if_no_path",
+.features      = "3 queue_if_no_path pg_init_retries 50",
 .hwhandler     = DEFAULT_HWHANDLER,
 .selector      = DEFAULT_SELECTOR,
 .pgpolicy      = GROUP_BY_PRIO,
 .pgfailback    = -FAILBACK_IMMEDIATE,
+.flush_on_last_del = FLUSH_ENABLED,
 .rr_weight     = RR_WEIGHT_NONE,
 .no_path_retry = NO_PATH_RETRY_UNDEF,
 .minio         = 128,

&lt;/pre&gt;</description>
    <dc:creator>Benjamin Marzinski</dc:creator>
    <dc:date>2012-05-23T21:42:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15906">
    <title>[PATCH][RESEND] multipath: fix scsi async tur checkercorruption</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15906</link>
    <description>&lt;pre&gt;Since the tur checker runs asynchronously in its own thread, there is nothing
that keeps a path from being orphaned or deleted before the tur thread has
finished. When this happenes the checker struct gets deleted.  However, the tur
thread might still we writing to that memory.  This can lead to memory
corruption.  This patch adds all of the necessary data to the checker context,
and makes the tur thread only use that. This way, if the checker is deleted
while the thread is still using the context, the thread will clean up the
context itself.

Since the context can only be freed when both the thread and the paths checker
structure have stopped needing it, and these can get get finished with the
context asychronously with respect to each other, the context has a holders
counter, protected by a spinlock, to keep track of the users.  When the
counter drops to zero, the context gets freed.

Signed-off-by: Benjamin Marzinski &amp;lt;bmarzins&amp;lt; at &amp;gt;redhat.com&amp;gt;
---
 libmultipath/checkers/tur.c |   85 +++++++++++++++++++++++++++&lt;/pre&gt;</description>
    <dc:creator>Benjamin Marzinski</dc:creator>
    <dc:date>2012-05-23T21:05:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15903">
    <title>[PATCH] multipath: Allow user_friendly_names in moreconfigsections</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15903</link>
    <description>&lt;pre&gt;This patch adds support for setting user_friendly_names in the devices and
multipaths config sections.

Signed-off-by: Benjamin Marzinski &amp;lt;bmarzins&amp;lt; at &amp;gt;redhat.com&amp;gt;
---
 libmultipath/config.c  |    2 +
 libmultipath/config.h  |    2 +
 libmultipath/dict.c    |   94 +++++++++++++++++++++++++++++++++++++++++++++----
 libmultipath/propsel.c |   14 ++++++-
 libmultipath/structs.h |    6 +++
 5 files changed, 110 insertions(+), 8 deletions(-)

Index: multipath-tools-120518/libmultipath/config.c
===================================================================
--- multipath-tools-120518.orig/libmultipath/config.c
+++ multipath-tools-120518/libmultipath/config.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -325,6 +325,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; merge_hwe (struct hwentry * dst, struct
 merge_num(flush_on_last_del);
 merge_num(fast_io_fail);
 merge_num(dev_loss);
+merge_num(user_friendly_names);
 
 return 0;
 }
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -383,6 +384,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; store_hwe (vector hwtable, struct hwentr
 hwe-&amp;gt;flush_on_last_del = dhwe-&amp;gt;flush_on_last_del;
 hwe-&amp;gt;fast_io_fail = dhwe-&amp;gt;fast_io_fail;
 hwe-&amp;gt;dev_los&lt;/pre&gt;</description>
    <dc:creator>Benjamin Marzinski</dc:creator>
    <dc:date>2012-05-23T20:36:30</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15902">
    <title>[PATCH] multipath: Make sure we store all the hwentryattributes.</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15902</link>
    <description>&lt;pre&gt;Not all of the attributes from the hardware table entries were getting stored
when the built-in devices configurations were being setup.

Signed-off-by: Benjamin Marzinski &amp;lt;bmarzins&amp;lt; at &amp;gt;redhat.com&amp;gt;
---
 libmultipath/config.c |    4 ++++
 1 file changed, 4 insertions(+)

Index: multipath-tools-120518/libmultipath/config.c
===================================================================
--- multipath-tools-120518.orig/libmultipath/config.c
+++ multipath-tools-120518/libmultipath/config.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -379,6 +379,10 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; store_hwe (vector hwtable, struct hwentr
 hwe-&amp;gt;no_path_retry = dhwe-&amp;gt;no_path_retry;
 hwe-&amp;gt;minio = dhwe-&amp;gt;minio;
 hwe-&amp;gt;minio_rq = dhwe-&amp;gt;minio_rq;
+hwe-&amp;gt;pg_timeout = dhwe-&amp;gt;pg_timeout;
+hwe-&amp;gt;flush_on_last_del = dhwe-&amp;gt;flush_on_last_del;
+hwe-&amp;gt;fast_io_fail = dhwe-&amp;gt;fast_io_fail;
+hwe-&amp;gt;dev_loss = dhwe-&amp;gt;dev_loss;
 
 if (dhwe-&amp;gt;bl_product &amp;amp;&amp;amp; !(hwe-&amp;gt;bl_product = set_param_str(dhwe-&amp;gt;bl_product)))
 goto out;

&lt;/pre&gt;</description>
    <dc:creator>Benjamin Marzinski</dc:creator>
    <dc:date>2012-05-23T20:29:05</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15900">
    <title>does file system page cache work after device mapping?</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15900</link>
    <description>&lt;pre&gt;Hi everyone, I have some questions regarding to the mechanism of device
mapper: After the device mapper layer gets the mapping information, it will
issue IO request to the real device. How does it perform IO operation at
this stage? For example, if the device is a block device, will it go to the
page cache and check whether the desired block is in cache? If the block is
not in cache and it read from the physical device, will the block be cached
in memory?

Thanks very much!


Zhiming
&lt;/pre&gt;</description>
    <dc:creator>zhiming shen</dc:creator>
    <dc:date>2012-05-22T19:18:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15892">
    <title>[PATCH]] multipath-tools : Minor typo inmultipath.conf.annotated</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15892</link>
    <description>&lt;pre&gt;path checking alorithm &amp;lt;= should be algorithm
---
  multipath.conf.annotated |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/multipath.conf.annotated b/multipath.conf.annotated
index c8e8218..8700d33 100644
--- a/multipath.conf.annotated
+++ b/multipath.conf.annotated
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -491,7 +491,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
  ##
  #              # name    : path_checker, checker
  #              # scope   : multipathd &amp;amp; multipathd
-#              # desc    : path checking alorithm to use to check path 
state
+#              # desc    : path checking algorithm to use to check path 
state
  #              # values  : 
readsector0|tur|emc_clariion|hp_sw|directio|rdac|
  #              #           cciss_tur
  #              #
&lt;/pre&gt;</description>
    <dc:creator>Cedric Buissart</dc:creator>
    <dc:date>2012-05-23T12:47:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15863">
    <title>[PATCH] dm-cache (block level disk cache target): UPDATElatest kernel</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15863</link>
    <description>&lt;pre&gt;A new patch for the 3.3.5 kernel.
Signed-off-by: Ming Zhao &amp;lt;dm-cache&amp;lt; at &amp;gt;xxxxxxxxxxxxxxxx&amp;gt;

URL:
http://visa.cs.fiu.edu/tiki/dm-cache

check the code also at:
https://github.com/mingzhao/dm-cache


-Dulcardo
&lt;/pre&gt;</description>
    <dc:creator>Dulcardo Arteaga</dc:creator>
    <dc:date>2012-05-22T20:40:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15845">
    <title>working with dm-raid module</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15845</link>
    <description>&lt;pre&gt;Hello!

I am engineer in Tver State University. We would like to use dm-raid driver in our storage system. But we must understand how we can rebuild the array (e.g raid1) and how mark a disk as failed. I have not found any documentation about it. Could you tell how to do it? 

Thank you for advice!

---
WBR, Andrew Zhukov
TvSU IC Dep


&lt;/pre&gt;</description>
    <dc:creator>Andrew Zhukov</dc:creator>
    <dc:date>2012-05-19T19:41:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15842">
    <title>[PATCH] multipath: clean up code for stopping the waiterthreads</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15842</link>
    <description>&lt;pre&gt;The way multipathd currently stops the waiter threads needs some work.
Right now they are stopped by being sent the SIGUSR1 signal. However their
cleanup code assumes that they are being cancelled, just like all the other
threads are.  There's no reason for them to be so unnecessarily
complicated and different from the other threads

This patch does a couple of things.  First, it removes the mutex from
the event_thread.  This wasn't doing anything. It was designed to protect
the wp-&amp;gt;mapname variable, which the waiter threads were checking to see
if they should quit. However, the mutex was only ever being used by the
thread itself, and it clearly didn't need to serialize with itself.  Also,
the function to clear the mapname, signal_waiter(), was set with
pthread_cleanup_push(), which never got called early, since the threads
weren't being cancelled.  Thus, the mapname never got cleared
until the pthreads were about to shut down.

The patch also rips out all the signal stopping code, and just uses
pthread_canc&lt;/pre&gt;</description>
    <dc:creator>Benjamin Marzinski</dc:creator>
    <dc:date>2012-05-19T06:37:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15841">
    <title>Changing some multipath defaults</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15841</link>
    <description>&lt;pre&gt;Now that we have better path selectors than round-robin, is seems kind
of silly to have all of our built-in device configs actually setting
their path selector to round-robin.  I think we should either
change the default, or not set a path selector in the builtin device
configs, unless the harware vendor thinks that one of them will
give the best performace. Personally I'd be in favor of doing both.
Removing them from the builtin device configs, and changing the default
to either queue-length or service-time.

Also, since we are now increasing dev_loss_tmo to make sure that devices
don't get removed before queue_if_no_path times out, it seems reasonable
to set a default value for fast_io_fail_tmo, so that devices which will
queue forever will actually fail back the IO in a reasonable time,
something like 5.

These would go a long way towards make the defaults work better on more
systems.  Any thoughts?

-Ben

&lt;/pre&gt;</description>
    <dc:creator>Benjamin Marzinski</dc:creator>
    <dc:date>2012-05-19T02:01:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15837">
    <title>[PATCH] multipath: fix select_no_path_retry for flushingdevices.</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15837</link>
    <description>&lt;pre&gt;The select_no_path_retry code was falling through if a flush was
in progress, and so it wasn't honoring flush_on_last_del.

Signed-off-by: Benjamin Marzinski &amp;lt;bmarzins&amp;lt; at &amp;gt;redhat.com&amp;gt;
---
 libmultipath/propsel.c |    1 +
 1 file changed, 1 insertion(+)

Index: multipath-tools-120403/libmultipath/propsel.c
===================================================================
--- multipath-tools-120403.orig/libmultipath/propsel.c
+++ multipath-tools-120403/libmultipath/propsel.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -415,6 +415,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; select_no_path_retry(struct multipath *m
 if (mp-&amp;gt;flush_on_last_del == FLUSH_IN_PROGRESS) {
 condlog(0, "flush_on_last_del in progress");
 mp-&amp;gt;no_path_retry = NO_PATH_RETRY_FAIL;
+return 0;
 }
 if (mp-&amp;gt;mpe &amp;amp;&amp;amp; mp-&amp;gt;mpe-&amp;gt;no_path_retry != NO_PATH_RETRY_UNDEF) {
 mp-&amp;gt;no_path_retry = mp-&amp;gt;mpe-&amp;gt;no_path_retry;

&lt;/pre&gt;</description>
    <dc:creator>Benjamin Marzinski</dc:creator>
    <dc:date>2012-05-18T22:33:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15791">
    <title>[PATCH] dm thin: fix table output when pool targetdisables discard passdown internally</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15791</link>
    <description>&lt;pre&gt;When the thin pool target clears the discard_passdown parameter
internally, it incorrectly reports this to userspace on the table line.
This patch corrects this by no longer changing the table line to reflect
that discard passdown was disabled.

We can still tell when discard passdown is overridden by looking for the
message "Discard unsupported by data device: Disabling discard passdown."

Signed-off-by: Mike Snitzer &amp;lt;snitzer&amp;lt; at &amp;gt;redhat.com&amp;gt;
---
 drivers/md/dm-thin.c |   12 ++++++++++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/md/dm-thin.c b/drivers/md/dm-thin.c
index 2fd87b5..d05fefd 100644
--- a/drivers/md/dm-thin.c
+++ b/drivers/md/dm-thin.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -497,6 +497,12 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; struct pool_features {
 unsigned zero_new_blocks:1;
 unsigned discard_enabled:1;
 unsigned discard_passdown:1;
+/*
+ * 'discard_passdown_original' preserves the value supplied to the
+ * constructor that could be overridden internally if the data device
+ * doesn't support discards.
+ */
+unsigned discard_pass&lt;/pre&gt;</description>
    <dc:creator>Mike Snitzer</dc:creator>
    <dc:date>2012-05-18T03:00:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15790">
    <title>[PATCH 00/13] Block cleanups (for bcache)</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15790</link>
    <description>&lt;pre&gt;From: Kent Overstreet &amp;lt;koverstreet&amp;lt; at &amp;gt;google.com&amp;gt;

Couple related things in this patch series. This is mostly stuff I did for
bcache, polished/expanded up a bit:

 * Bio pool freeing. This moves freeing of bios allocated from bio pools into
   generic code.

 * Kill bi_destructor. That was Tejun's idea, but it turned out to be easier
   than I expected.

 * Improved bio splitting. This was originally part of bcache, but I pulled it
   out and replaced the existing bio splitting code with it.

 * Closures - this is from bcache. I didn't really need to use it for the next
   patch, but IMO it makes the code a bit more elegant.

 * Make generic_make_request() handle arbitrary size bios. I think this is
   going to enable a lot of cleanups in the future.

   The idea here isn't for generic_make_request() to be doing the splitting in
   practice long term, it's more just an intermediate stage. If this goes in, I
   think a lot of driver code - certainly a lot of virtual block drivers -
   could easily be made to han&lt;/pre&gt;</description>
    <dc:creator>koverstreet&lt; at &gt;google.com</dc:creator>
    <dc:date>2012-05-18T02:59:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15783">
    <title>multipathd: 8:80 mark as failed - BUG: unable to handle kernel NULL pointer dereference at (null)</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15783</link>
    <description>&lt;pre&gt;Hello,
I've compiled and installed on January on Opensuse 11.4 x64 from
git://git.kernel.org/pub/scm/linux/storage/multipath/hare/multipath-tools.git
the multipath-tools but previous 14 of May the module hang as described
below.
Now I've got
git-clone -b sles11-sp2
git://git.kernel.org/pub/scm/linux/storage/multipath/hare/multipath-tools.git
.
and reinstalled, but I'd like to know if this problem was already resolved.

Regards,
Roberto.

/May 14 10:39:20 nodo4 multipathd: 8:80: mark as failed
May 14 10:39:20 nodo4 multipathd: xenimages2: remaining active paths: 3
May 14 10:39:20 nodo4 kernel: [9480398.044082]  rport-3:0-1: blocked FC
remote port time out: removing target and saving binding
May 14 10:39:20 nodo4 kernel: [9480398.044146]  rport-3:0-0: blocked FC
remote port time out: removing target and saving binding
May 14 10:39:20 nodo4 kernel: [9480398.044238] sd 3:0:1:0: [sdf]
Unhandled error code
May 14 10:39:20 nodo4 kernel: [9480398.044241] sd 3:0:1:0: [sdf] 
Result: hostbyte=DID_NO_CONNECT driverbyte=&lt;/pre&gt;</description>
    <dc:creator>Roberto Giordani</dc:creator>
    <dc:date>2012-05-17T09:56:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15779">
    <title>[PATCH] [dm-thin] Allow userland access to metadata of alive thin provisioning pool</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15779</link>
    <description>&lt;pre&gt;New feature.

This patch implements two new messages that can be sent to the thin
pool target allowing it to take a snapshot of the _metadata_.  This,
read-only snapshot can be accessed by userland, concurrently with the
live target.

Only one metadata snapshot can be held at a time.  The pool's status
line will give the block location for the current msnap.

The thin-provisioning-tools have been updated to v0.1.5.  The
thin_dump program can now be used to display the msnap.  eg,

    thin_dump -m &amp;lt;msnap root&amp;gt; &amp;lt;metadata dev&amp;gt;

Available here: https://github.com/jthornber/thin-provisioning-tools

Now that userland can access the metadata we can do various things
that have traditionally been kernel side tasks:

     i) Incremental backups.

     By using metadata snapshots we can work out what blocks have
     changed over time.  Combined with data snapshots we can ensure
     the data doesn't change while we back it up.

     A short proof of concept script can be found here:

     https://github.com/jthornber&lt;/pre&gt;</description>
    <dc:creator>Joe Thornber</dc:creator>
    <dc:date>2012-05-17T14:47:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15771">
    <title>[PATCH] dm thin: commit pool's metadata on last close ofthin device</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15771</link>
    <description>&lt;pre&gt;Reinstate dm_flush_all and dm_table_flush_all.  dm_blk_close will
now trigger the .flush method of all targets within a table on the last
close of a DM device.

In the case of the thin target, the thin_flush method will commit the
backing pool's metadata.

Doing so avoids a deadlock that has been observed with the following
sequence (as can be triggered via "dmsetup remove_all"):
- IO is issued to a thin device, thin device is closed
- pool's metadata device is suspended before the pool is
- because the pool still has outstanding IO we deadlock because the
  pool's metadata device is suspended

Signed-off-by: Mike Snitzer &amp;lt;snitzer&amp;lt; at &amp;gt;redhat.com&amp;gt;
Cc: stable&amp;lt; at &amp;gt;vger.kernel.org
---
 drivers/md/dm-table.c |    9 +++++++++
 drivers/md/dm-thin.c  |   19 +++++++++++++++++++
 drivers/md/dm.c       |   20 +++++++++++++++++++-
 drivers/md/dm.h       |    1 +
 4 files changed, 48 insertions(+), 1 deletions(-)

diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index 2e227fb..077fff8 100644
--- a/drivers/md/dm-table.c&lt;/pre&gt;</description>
    <dc:creator>Mike Snitzer</dc:creator>
    <dc:date>2012-05-16T22:19:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15765">
    <title>Bumping multipath-tools version</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15765</link>
    <description>&lt;pre&gt;Given the amount of change in the tools, I was wondering if we should
bump the release version.

-Ben

&lt;/pre&gt;</description>
    <dc:creator>Benjamin Marzinski</dc:creator>
    <dc:date>2012-05-16T15:05:32</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15747">
    <title>Multipath and LVM (lvdisplay takes 30Secs)</title>
    <link>http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/15747</link>
    <description>&lt;pre&gt;Hello List,

i am using multipath for redundance reasons. But something seems to be dodgy.

"lvdisplay" takes 30Seconds.

"multipath" -l shows nothing

multipath -l -v 2
SAN (3600a0b80001f7557000032864ce4aff3) dm-0 IBM,1722-600
size=250G features='1 queue_if_no_path' hwhandler='1 rdac' wp=rw
|-+- policy='round-robin 0' prio=-1 status=active
| `- 2:0:1:0 sdb 8:16 active undef running
|-+- policy='round-robin 0' prio=-1 status=enabled
| `- 3:0:1:0 sdd 8:48 active undef running
`-+- policy='round-robin 0' prio=-1 status=enabled
  `- 3:0:0:0 sdc 8:32 active undef running

Any idea why lvmdisplay takes so long? If i can see its trying to read
from sda, dm-1, sdb, dm-1 where the "read(3, " operations need some
time each time.

Here is some more info:

multipath -l -v 3
May 15 12:10:06 | sdb: not found in pathvec
May 15 12:10:06 | sdb: mask = 0x1
May 15 12:10:06 | sdb: dev_t = 8:16
May 15 12:10:06 | sdb: size = 524288000
May 15 12:10:06 | sdb: subsystem = scsi
May 15 12:10:06 | sdb: vendor = IBM
May 15 12:10:06 | s&lt;/pre&gt;</description>
    <dc:creator>ml ml</dc:creator>
    <dc:date>2012-05-15T10:15:09</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.kernel.device-mapper.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.kernel.device-mapper.devel</link>
  </textinput>
</rdf:RDF>

