Linux Device-Mapper Development

• Thread Index

• [PATCH 07/11] [dm-thin] Commit every second to prevent too much of a position building up.
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• [PATCH 03/11] [PATCH 18/19] [dm-thin] [bio prison] Don't use the bi_next field for the holder of a cell.
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• [PATCH 08/11] [dm-thin] Add support for external origins.
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• [PATCH 04/11] [PATCH 15/19] [dm-thin] dm_thin_remove_block() wasn't decrementing the mapped_blocks counter.
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• [PATCH 05/11] [dm-thin] btree-remove - fix rebalancing of 3 nodes.
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• [PATCH 06/11] Remove entries from the ref_count tree if they're no longer needed.
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• [PATCH 11/11] [dm-thin] some tidy ups of the __open_device() error path (Mike Snitzer)
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• [PATCH 01/11] Unlock the superblock on an error path for new metadata dev creation.
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• [PATCH 09/11] [dm-thin] Discard support part 1
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• [PATCH 10/11] [dm-thin] Add support for REQ_DISCARD
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• [PATCH 02/11] Remove redundant arg from value_ptr()
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• [PATCH 00/11] Latest dm-thin patches
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• Re: [PATCH] scsi : Adding all the definitions of host bytes in hostbyte_table
  • From: Hannes Reinecke <hare@xxxxxxx>
• [PATCH] scsi : Adding all the definitions of host bytes in hostbyte_table
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• [PATCH] scsi_dh_rdac: Fix for unbalanced reference count
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• [09/20] dm: do not forward ioctls from logical volumes to the underlying device
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [linux-lvm] New LVM2 release 2.02.89: Thinly-provisioned logical volumes
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: [linux-lvm] New LVM2 release 2.02.89: Thinly-provisioned logical volumes
  • From: "Busby.Cheung" <chaimvy@xxxxxxx>
• [PATCH] scsi_dh_rdac: Fix for unbalanced reference count
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: [linux-lvm] New LVM2 release 2.02.89: Thinly-provisioned logical volumes
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [linux-lvm] New LVM2 release 2.02.89: Thinly-provisioned logical volumes
  • From: "Busby.Cheung" <chaimvy@xxxxxxx>
• Re: [linux-lvm] New LVM2 release 2.02.89: Thinly-provisioned logical volumes
  • From: "Busby.Cheung" <chaimvy@xxxxxxx>
• Re: Tutorial or sample code for device mapper
  • From: Frederick Grose <fgrose@xxxxxxxxx>
• Re: [PATCH] block: add missing block_bio_complete() tracepoint
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: git source repository
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: [PATCH] backing-dev: use synchronize_rcu_expedited instead of synchronize_rcu
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH] backing-dev: use synchronize_rcu_expedited instead of synchronize_rcu
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [linux-lvm] New LVM2 release 2.02.89: Thinly-provisioned logical volumes
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [linux-lvm] New LVM2 release 2.02.89: Thinly-provisioned logical volumes
  • From: "Busby.Cheung" <chaimvy@xxxxxxx>
• Tutorial or sample code for device mapper
  • From: George Shuklin <george.shuklin@xxxxxxxxx>
• git source repository
  • From: "Ing. Mario De Chenno" <mario.dechenno@xxxxxxxxx>
• Re: [PATCH] block: add missing block_bio_complete() tracepoint
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH] block: add missing block_bio_complete() tracepoint
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [PATCH] DM RAID: Fix memory corruption caused by repeated calls to bitmap_load
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] block: add missing block_bio_complete() tracepoint
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [linux-lvm] ??????: New LVM2 release 2.02.89: Thinly-provisioned logical?volumes
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• 答复: [linux-lvm] New LVM2 release 2.02.89: Thinly-provisioned logical volumes
  • From: Kirby Zhou <kirbyzhou@xxxxxxxxxxxxxxxxx>
• Re: [linux-lvm] 答复: New LVM2 release 2.02.89: Thinly-provisioned logical?volumes
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH] block: add missing block_bio_complete() tracepoint
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [PATCH] block: add missing block_bio_complete() tracepoint
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [PATCH] block: add missing block_bio_complete() tracepoint
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH] block: add missing block_bio_complete() tracepoint
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [PATCH] block: add missing block_bio_complete() tracepoint
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH] block: add missing block_bio_complete() tracepoint
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [PATCH] block: add missing block_bio_complete() tracepoint
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH] block: add missing block_bio_complete() tracepoint
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [PATCH] block: add missing block_bio_complete() tracepoint
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [PATCH] block: add missing block_bio_complete() tracepoint
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH] block: add missing block_bio_complete() tracepoint
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH] block: add missing block_bio_complete() tracepoint
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: dm-thin vs lvm performance
  • From: Jagan Reddy <gjmsreddy@xxxxxxxxx>
• [PATCH] multipath: Update multipath.conf man page
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• [PATCH] multipath: Update multipath device on show topology
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• Re: dd to a striped device with 9 disks gets much lower throughput when oflag=direct used
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: dd to a striped device with 9 disks gets much lower throughput when oflag=direct used
  • From: Richard Sharpe <realrichardsharpe@xxxxxxxxx>
• Re: dd to a striped device with 9 disks gets much lower throughput when oflag=direct used
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: "Ted Ts'o" <tytso@xxxxxxx>
• Re: About the thin provision function @ kernel 3.2 or later.
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Receiving device failure/removal notification within a dm-target
  • From: Siddharth Choudhuri <sid.kernel@xxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: "Loke, Chetan" <Chetan.Loke@xxxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Wu Fengguang <fengguang.wu@xxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Wu Fengguang <fengguang.wu@xxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: "Loke, Chetan" <Chetan.Loke@xxxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: "Loke, Chetan" <Chetan.Loke@xxxxxxxxxxxx>
• Re: dd to a striped device with 9 disks gets much lower throughput when oflag=direct used
  • From: Richard Sharpe <realrichardsharpe@xxxxxxxxx>
• Re: dd to a striped device with 9 disks gets much lower throughput when oflag=direct used
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: dd to a striped device with 9 disks gets much lower throughput when oflag=direct used
  • From: Richard Sharpe <realrichardsharpe@xxxxxxxxx>
• Re: dm-thin vs lvm performance
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• [PATCH] DM RAID: Fix memory corruption caused by repeated calls to bitmap_load
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• Re: [PATCH 0/3][RESEND]multipath-tools: mpathpersist utility for managing persistent reservation on dm multipath device.
  • From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxxxxx>
• Re: dd to a striped device with 9 disks gets much lower throughput when oflag=direct used
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: dd to a striped device with 9 disks gets much lower throughput when oflag=direct used
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Andreas Dilger <adilger@xxxxxxxxx>
• New LVM2 release 2.02.89: Thinly-provisioned logical volumes
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• dd to a striped device with 9 disks gets much lower throughput when oflag=direct used
  • From: Richard Sharpe <realrichardsharpe@xxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jan Kara <jack@xxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Andreas Dilger <adilger@xxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: "Loke, Chetan" <Chetan.Loke@xxxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: "Loke, Chetan" <Chetan.Loke@xxxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: "Loke, Chetan" <Chetan.Loke@xxxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: "Loke, Chetan" <Chetan.Loke@xxxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Andreas Dilger <adilger@xxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jan Kara <jack@xxxxxxx>
• Re: [PATCH 2/2] scsi : fixing the new host byte settings (DID_TARGET_FAILURE and DID_NEXUS_FAILURE)
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Andrea Arcangeli <aarcange@xxxxxxxxxx>
• Re: [PATCH 2/2] scsi : fixing the new host byte settings (DID_TARGET_FAILURE and DID_NEXUS_FAILURE)
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: [PATCH 0/3][RESEND]multipath-tools: mpathpersist utility for managing persistent reservation on dm multipath device.
  • From: Fil <lists@xxxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Chris Mason <chris.mason@xxxxxxxxxx>
• Re: [PATCH 0/3][RESEND]multipath-tools: mpathpersist utility for managing persistent reservation on dm multipath device.
  • From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Steven Whitehouse <swhiteho@xxxxxxxxxx>
• Re: [PATCH 0/3][RESEND]multipath-tools: mpathpersist utility for managing persistent reservation on dm multipath device.
  • From: Fil <lists@xxxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jan Kara <jack@xxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Steven Whitehouse <swhiteho@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jan Kara <jack@xxxxxxx>
• Re: [LSF/MM TOPIC] a few storage topics
  • From: Douglas Gilbert <dgilbert@xxxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Wu Fengguang <fengguang.wu@xxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Wu Fengguang <fengguang.wu@xxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Andreas Dilger <aedilger@xxxxxxxxx>
• Re: [PATCH 0/3][RESEND]multipath-tools: mpathpersist utility for managing persistent reservation on dm multipath device.
  • From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Andreas Dilger <adilger@xxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Andreas Dilger <adilger@xxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: NeilBrown <neilb@xxxxxxx>
• Re: dm-thin vs lvm performance
  • From: Jagan Reddy <gjmsreddy@xxxxxxxxx>
• Re: [PATCH 2/2] scsi : fixing the new host byte settings (DID_TARGET_FAILURE and DID_NEXUS_FAILURE)
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jan Kara <jack@xxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jan Kara <jack@xxxxxxx>
• [PATCH 2/2] scsi : fixing the new host byte settings (DID_TARGET_FAILURE and DID_NEXUS_FAILURE)
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• [PATCH 1/2] scsi : Correctly setting the scsi host/msg/status bytes
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jan Kara <jack@xxxxxxx>
• Re: [LSF/MM TOPIC] a few storage topics
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Chris Mason <chris.mason@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: [LSF/MM TOPIC] a few storage topics
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Chris Mason <chris.mason@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Andrea Arcangeli <aarcange@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Chris Mason <chris.mason@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Andreas Dilger <adilger@xxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Chris Mason <chris.mason@xxxxxxxxxx>
• [PATCH 5/5] [dm-thin] [space-map-common] Remove entries from the ref_count tree if they're no longer needed.
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• [PATCH 4/5] [dm-thin] [btree-remove] Fix bug that allowed the nr of entries in a btree node to drop below 1/3.
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• [PATCH 1/5] [dm-thin] Remove redundant arg from value_ptr()
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• [PATCH 3/5] [dm-thin] [btree-remove] break up __rebalance3 function.
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• [PATCH 2/5] [dm-thin] Remove 2 BUG_ONs from btree_remove code.
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• [PATCH 0/5] [dm-thin] btree remove tweaks
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• Re: [PATCH 0/3][RESEND]multipath-tools: mpathpersist utility for managing persistent reservation on dm multipath device.
  • From: Fil <lists@xxxxxxxxxxxx>
• Re: [PATCH 0/3][RESEND]multipath-tools: mpathpersist utility for managing persistent reservation on dm multipath device.
  • From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxxxxx>
• [092/129] dm: do not forward ioctls from logical volumes to the underlying device
  • From: Greg KH <gregkh@xxxxxxx>
• [PATCH] dm-crypt: add missing error handling
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [63/90] dm: do not forward ioctls from logical volumes to the underlying device
  • From: Greg KH <gregkh@xxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Andrea Arcangeli <aarcange@xxxxxxxxxx>
• [PATCH 2/2] scsi : fixing the new host byte settings (DID_TARGET_FAILURE and DID_NEXUS_FAILURE)
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• [PATCH 1/2] scsi : Correctly setting the scsi host/msg/status bytes
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Andrea Arcangeli <aarcange@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jan Kara <jack@xxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jan Kara <jack@xxxxxxx>
• Re: dm-thin vs lvm performance
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• [PATCH 2/2] Add support for external origins.
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• [PATCH 0/2] External origin support for thin provisioning
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• [PATCH 1/2] Unlock the superblock on an error path for new metadata dev creation.
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
• Re: BUG: spinlock trylock failure on UP on CPU#0, vgchange/936
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: BUG: spinlock trylock failure on UP on CPU#0, vgchange/936
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: BUG: spinlock trylock failure on UP on CPU#0, vgchange/936
  • From: Christian Kujau <lists@xxxxxxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
• Re: BUG: spinlock trylock failure on UP on CPU#0, vgchange/936
  • From: Christian Kujau <lists@xxxxxxxxxxxxxxx>
• Re: BUG: spinlock trylock failure on UP on CPU#0, vgchange/936
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: BUG: spinlock trylock failure on UP on CPU#0, vgchange/936
  • From: Christian Kujau <lists@xxxxxxxxxxxxxxx>
• Re: BUG: spinlock trylock failure on UP on CPU#0, vgchange/936
  • From: Jens Axboe <axboe@xxxxxxxxx>
• Re: BUG: spinlock trylock failure on UP on CPU#0, vgchange/936
  • From: Christian Kujau <lists@xxxxxxxxxxxxxxx>
• Re: dm-thin vs lvm performance
  • From: Jagan Reddy <gjmsreddy@xxxxxxxxx>
• Re: dm-thin vs lvm performance
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: dm-thin vs lvm performance
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: dm-thin vs lvm performance
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH 0/3][RESEND]multipath-tools: mpathpersist utility for managing persistent reservation on dm multipath device.
  • From: Fil <lists@xxxxxxxxxxxx>
• Re: dmsetup fails on latest kernel
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: dmsetup fails on latest kernel
  • From: "Kasatkin, Dmitry" <dmitry.kasatkin@xxxxxxxxx>
• Re: dmsetup fails on latest kernel
  • From: "Kasatkin, Dmitry" <dmitry.kasatkin@xxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Andrea Arcangeli <aarcange@xxxxxxxxxx>
• Re: [PATCH] block: Invalidate the cache for a parent block-device
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: dmsetup fails on latest kernel
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: dmsetup fails on latest kernel
  • From: "H. Peter Anvin" <hpa@xxxxxxxxxxxxxxx>
• Re: dmsetup fails on latest kernel
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: dmsetup fails on latest kernel
  • From: "H. Peter Anvin" <hpa@xxxxxxxxxxxxxxx>
• Re: dmsetup fails on latest kernel
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jan Kara <jack@xxxxxxx>
• Re: dmsetup fails on latest kernel
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• [PATCH 3/3][RESEND]multipath-tools: fix 32 fingerprint limit in multipathd and path discovery
  • From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxxxxx>
• [PATCH 2/3][RESEND]multipath-tools: Changes in multipath-tools to handles pr management of data path life cycle and state changes.
  • From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxxxxx>
• [PATCH 1/3][RESEND]multipath-tools: Add mpathpersist utility and libmpathpersist library for mpath pr management
  • From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxxxxx>
• [PATCH 0/3][RESEND]multipath-tools: mpathpersist utility for managing persistent reservation on dm multipath device.
  • From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxxxxx>
• Re: dmsetup fails on latest kernel
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: dmsetup fails on latest kernel
  • From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Andrea Arcangeli <aarcange@xxxxxxxxxx>
• Re: (no subject)
  • From: "Kasatkin, Dmitry" <dmitry.kasatkin@xxxxxxxxx>
• Re: (no subject)
  • From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
• Re: dmsetup fails on latest kernel
  • From: "Kasatkin, Dmitry" <dmitry.kasatkin@xxxxxxxxx>
• Re: dmsetup fails on latest kernel
  • From: "Kasatkin, Dmitry" <dmitry.kasatkin@xxxxxxxxx>
• Re: Multisnap / dm-thin
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Dan Williams <dan.j.williams@xxxxxxxxx>
• dmsetup fails on latest kernel
  • From: "Kasatkin, Dmitry" <dmitry.kasatkin@xxxxxxxxx>
• Re: [node-devel] [ovirt-devel] blockdev --flushbufs required [was: parted issue/question
  • From: Alan Pevec <apevec@xxxxxxxxx>
• Re: [ovirt-devel] blockdev --flushbufs required [was: parted issue/question
  • From: Mike Burns <mburns@xxxxxxxxxx>
• Re: [node-devel] [ovirt-devel] blockdev --flushbufs required [was: parted issue/question
  • From: Jim Meyering <jim@xxxxxxxxxxxx>
• (no subject)
  • From: "Kasatkin, Dmitry" <dmitry.kasatkin@xxxxxxxxx>
• dmsetup fails on latest kernel
  • From: "Kasatkin, Dmitry" <dmitry.kasatkin@xxxxxxxxx>
• Re: Multisnap / dm-thin
  • From: Spelic <spelic@xxxxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jan Kara <jack@xxxxxxx>
• Re: Multisnap / dm-thin
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: About the thin provision function @ kernel 3.2 or later.
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jan Kara <jack@xxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
• Re: dm-thin vs lvm performance
  • From: Jagan Reddy <gjmsreddy@xxxxxxxxx>
• Re: blockdev --flushbufs required [was: parted issue/question
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: blockdev --flushbufs required [was: parted issue/question
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• blockdev --flushbufs required [was: parted issue/question
  • From: Jim Meyering <jim@xxxxxxxxxxxx>
• Multisnap / dm-thin
  • From: Spelic <spelic@xxxxxxxxxxxxx>
• BUG: spinlock trylock failure on UP on CPU#0, vgchange/936
  • From: Christian Kujau <lists@xxxxxxxxxxxxxxx>
• Re: parted issue/question
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: parted issue/question
  • From: Jim Meyering <jim@xxxxxxxxxxxx>
• Re: [Lsf-pc] [LSF/MM TOPIC] a few storage topics
  • From: Jan Kara <jack@xxxxxxx>
• [LSF/MM TOPIC] a few storage topics
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: About the thin provision function @ kernel 3.2 or later.
  • From: "Ted Ts'o" <tytso@xxxxxxx>
• [PATCH 3/3] block: don't export block_bio_complete tracepoint
  • From: Namhyung Kim <namhyung.kim@xxxxxxx>
• Re: About the thin provision function @ kernel 3.2 or later.
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH stable 3/3] dm: do not forward ioctls from logical volumes to the underlying device
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• multipath-tools/libmultipath hwtable.c
  • From: bmarzins@xxxxxxxxxxxxxx
• Re: About the thin provision function @ kernel 3.2 or later.
  • From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
• [PATCH stable 3/3] dm: do not forward ioctls from logical volumes to the underlying device
  • From: Paolo Bonzini <pbonzini@xxxxxxxxxx>
• Re: About the thin provision function @ kernel 3.2 or later.
  • From: "Ted Ts'o" <tytso@xxxxxxx>
• Re: About the thin provision function @ kernel 3.2 or later.
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: About the thin provision function @ kernel 3.2 or later.
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• About the thin provision function @ kernel 3.2 or later.
  • From: Yukihito HARA <yukihito.hara623@xxxxxxxxx>
• Re: dm-thin vs lvm performance
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH] There's no need to include linux/version.h in drivers/md/dm-bufio.c
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] drivers/md/dm-ioctl.c::target_message(): don't leak 'argv' mem
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH] dm-crypt: fix possible mempool deadlock
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH] There's no need to include linux/version.h in drivers/md/dm-bufio.c
  • From: Jesper Juhl <jj@xxxxxxxxxxxxx>
• [PATCH] drivers/md/dm-ioctl.c::target_message(): don't leak 'argv' mem
  • From: Jesper Juhl <jj@xxxxxxxxxxxxx>
• Re: [PATCH] multipath: make tgt_node_name work for iscsi devices
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: [PATCH] multipath: don't remove dm device on remove uevent
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: kpartx -l side effects
  • From: Pádraig Brady <pbrady@xxxxxxxxxx>
• communication between a dm target and a userspace application
  • From: HyoGi Sim <sandrain@xxxxxxxxx>
• Re: kpartx -l side effects
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH v2 3/3] dm: do not forward ioctls from logical volumes to the underlying device
  • From: Paolo Bonzini <pbonzini@xxxxxxxxxx>
• Re: kpartx -l side effects
  • From: Pádraig Brady <pbrady@xxxxxxxxxx>
• [PATCH] multipath: don't remove dm device on remove uevent
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• [PATCH] multipath: make tgt_node_name work for iscsi devices
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• [PATCH] scsi : Adding all the definitions of host bytes in hostbyte_table
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• dm-thin vs lvm performance
  • From: Jagan Reddy <gjmsreddy@xxxxxxxxx>
• Re: kpartx -l side effects
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: kpartx return codes
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• kpartx -l side effects
  • From: Pádraig Brady <pbrady@xxxxxxxxxx>
• Re: kpartx return codes
  • From: Pádraig Brady <pbrady@xxxxxxxxxx>
• Re: [PATCH] Add default values for IBM XIV Storage System.
  • From: Oren Held <oren@xxxxxxxxxxx>
• Re: Crash in dm_done()
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH] Add default values for IBM XIV Storage System.
  • From: August Sodora <augsod@xxxxxxxxx>
• Re: Crash in dm_done()
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Crash in dm_done()
  • From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
• Re: [PATCH v2] scsi_dh_alua: Retry the check-condition in case Mode Parameters Changed
  • From: James Bottomley <jbottomley@xxxxxxxxxxxxx>
• [PATCH v2] scsi_dh_alua: Retry the check-condition in case Mode Parameters Changed
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: scsi_dh_alua: Retry the check-condition in case Mode Parameters Changed
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: dm thin provision, pool full
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• dm thin provision, pool full
  • From: Marcus Sorensen <marcus@xxxxxxxxxxxxxxxxx>
• Re: dm thin metadata: clarify __open_device functionality and fix callers
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Crash in dm_done()
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH] dm thin metadata: clarify __open_device functionality and fix callers
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• [PATCH] dm thin metadata: clarify __open_device functionality and fix callers
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH] Don't add 'p' delimiter when you shouldn't
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• Re: Write protected devices, unexpected dm-multipath queueing
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH] scsi_dh_alua: Retry the check-condition in case Mode Parameters Changed
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: Write protected devices, unexpected dm-multipath queueing
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: Write protected devices, unexpected dm-multipath queueing
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Write protected devices, unexpected dm-multipath queueing
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Write protected devices, unexpected dm-multipath queueing
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Write protected devices, unexpected dm-multipath queueing
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: [RFC PATCH] Track block device users that created dirty pages
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: can't recover ext4 on lvm from ext4_mb_generate_buddy:739: group 1687, 32254 clusters in bitmap, 32258 in gd
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: can't recover ext4 on lvm from ext4_mb_generate_buddy:739: group 1687, 32254 clusters in bitmap, 32258 in gd
  • From: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
• Re: can't recover ext4 on lvm from ext4_mb_generate_buddy:739: group 1687, 32254 clusters in bitmap, 32258 in gd
  • From: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
• Re: can't recover ext4 on lvm from ext4_mb_generate_buddy:739: group 1687, 32254 clusters in bitmap, 32258 in gd
  • From: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
• Re: can't recover ext4 on lvm from ext4_mb_generate_buddy:739: group 1687, 32254 clusters in bitmap, 32258 in gd
  • From: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
• Re: [RFC PATCH] Track block device users that created dirty pages
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• [RFC PATCH] Track block device users that created dirty pages
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: better alternative to part multpath -l output?
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: can't recover ext4 on lvm from ext4_mb_generate_buddy:739: group 1687, 32254 clusters in bitmap, 32258 in gd
  • From: "Ted Ts'o" <tytso@xxxxxxx>
• Re: better alternative to part multpath -l output?
  • From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
• better alternative to part multpath -l output?
  • From: Rudy Gevaert <Rudy.Gevaert@xxxxxxxx>
• DM suspend locks up under load?
  • From: David Shaw <dshaw@xxxxxxxxxxxxxxx>
• [PATCH] dm: verity target
  • From: Mandeep Singh Baines <msb@xxxxxxxxxxxx>
• [PATCH] dm: verity target
  • From: Mandeep Singh Baines <msb@xxxxxxxxxxxx>
• Re: [PATCH] multipath: fix scsi async tur checker corruption
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• Re: mpathpersist
  • From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: mpathpersist
  • From: Fil <lists@xxxxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• Re: mpathpersist
  • From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxxxxx>
• Re: mpathpersist
  • From: Fil <lists@xxxxxxxxxxxx>
• Re: mpathpersist
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• mpathpersist
  • From: Fil <lists@xxxxxxxxxxxx>
• Re: [PATCH] Add default values for IBM XIV Storage System.
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• [PATCH] Add default values for IBM XIV Storage System.
  • From: Oren Held <orenhe@xxxxxxxxxx>
• Re: [Multipath] Round-robin performance limit
  • From: "John A. Sullivan III" <jsullivan@xxxxxxxxxxxxxxxxxxx>
• [PATCH 2/2] block: don't export block_bio_complete tracepoint
  • From: Namhyung Kim <namhyung@xxxxxxxxx>
• Re: [Multipath] Round-robin performance limit
  • From: Pasi Kärkkäinen <pasik@xxxxxx>
• Re: [PATCH] multipath: fix scsi timeout code
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: [RFC][PATCH 0/3] persistent management feature for multipath-tools
  • From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxxxxx>
• [CFP] Linux Storage, Filesystem & Memory Management Summit 2012 (April 1-2)
  • From: "Williams, Dan J" <dan.j.williams@xxxxxxxxx>
• Re: [Multipath] Round-robin performance limit
  • From: "John A. Sullivan III" <jsullivan@xxxxxxxxxxxxxxxxxxx>
• Re: FW: CVE-2011-4127 kernel: possible privilege escalation via SG_IO ioctl
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• FW: CVE-2011-4127 kernel: possible privilege escalation via SG_IO ioctl
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• [PATCH] dm: verity target
  • From: Mandeep Singh Baines <msb@xxxxxxxxxxxx>
• [PATCH] scsi_dh_alua: Retry the check-condition in case Mode Parameters Changed
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: how to troubleshoot faulty multipath path?
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: how to troubleshoot faulty multipath path?
  • From: Rudy Gevaert <Rudy.Gevaert@xxxxxxxx>
• Re: [PATCH] multipath: fix scsi async tur checker corruption
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• Re: mempool && io_schedule_timeout()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH] multipath: fix scsi async tur checker corruption
  • From: Hannes Reinecke <hare@xxxxxxx>
• [PATCH] multipath: fix scsi async tur checker corruption
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• Re: how to troubleshoot faulty multipath path?
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: [RFC][PATCH 0/3] persistent management feature for multipath-tools
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH] multipath: fix scsi timeout code
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [RFC][PATCH 0/3] persistent management feature for multipath-tools
  • From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxxxxx>
• Re: [RFC][PATCH 0/3] persistent management feature for multipath-tools
  • From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxxxxx>
• [PATCH] multipath: fix scsi timeout code
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• Re: [RFC][PATCH 0/3] persistent management feature for multipath-tools
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: [PATCH V2] multipath: add option to change the number of error messages
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• [PATCH] multipath: add option to change the number of error messages
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• Re: [RFC][PATCH 0/3] persistent management feature for multipath-tools
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• dmraid ./configure ./configure.in autoconf/con ...
  • From: heinzm@xxxxxxxxxxxxxx
• [RFC][PATCH 1/3] persistent management feature for multipath-tools
  • From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxxxxx>
• [RFC][PATCH 1/3] persistent management feature for multipath-tools
  • From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxxxxx>
• [RFC][PATCH 2/3] persistent management feature for multipath-tools
  • From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxxxxx>
• [RFC][PATCH 3/3] persistent management feature for multipath-tools
  • From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxxxxx>
• [RFC][PATCH 0/3] persistent management feature for multipath-tools
  • From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxxxxx>
• dmraid/tools VERSION
  • From: heinzm@xxxxxxxxxxxxxx
• dmraid CHANGELOG
  • From: heinzm@xxxxxxxxxxxxxx
• Re: how to troubleshoot faulty multipath path?
  • From: "Rudy Gevaert" <Rudy.Gevaert@xxxxxxxx>
• Re: how to troubleshoot faulty multipath path?
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• how to troubleshoot faulty multipath path?
  • From: Rudy Gevaert <Rudy.Gevaert@xxxxxxxx>
• Re: Compiling/linking applications using libdevmapper
  • From: Yathindra <ydev@xxxxxxxxxxx>
• Re: [GIT PULL] Queue free fix (was Re: [PATCH] block: Free queue resources at blk_release_queue())
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Compiling/linking applications using libdevmapper
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Compiling/linking applications using libdevmapper
  • From: Yathindra <ydev@xxxxxxxxxxx>
• Re: [GIT PULL] Queue free fix (was Re: [PATCH] block: Free queue resources at blk_release_queue())
  • From: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
• Re: ERROR: asr: reading /dev/sdo[Input/output error]
  • From: Christian May <cmay@xxxxxxxxxxxxxxxxxx>
• Re: ERROR: asr: reading /dev/sdo[Input/output error]
  • From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
• Re: ERROR: asr: reading /dev/sdo[Input/output error]
  • From: Christian May <cmay@xxxxxxxxxxxxxxxxxx>
• kpartx return codes
  • From: Pádraig Brady <pbrady@xxxxxxxxxx>
• Re: ERROR: asr: reading /dev/sdo[Input/output error]
  • From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
• ERROR: asr: reading /dev/sdo[Input/output error]
  • From: Christian May <cmay@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH] multipath-tools: Remove bad udev rules
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• [PATCH] multipath-tools: Remove bad udev rules
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• Re: dm-mpath: Clear map_context pointer when requeuing
  • From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
• [PATCH] dm: add documentation of sysfs interface
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• [PATCH v2] dm: fix discard support in dm_io
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: dm-mpath: Clear map_context pointer when requeuing
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH] dm-mpath: Clear map_context pointer when requeuing
  • From: Dave Wysochanski <dwysocha@xxxxxxxxxx>
• Re: dm-mpath: Clear map_context pointer when requeuing
  • From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
• [PATCH] DM RAID: Fix inability to handle failed devices during start-up
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• Re: DM_snapshot_cow filesystem (dmsetup create snapshot)
  • From: Frederick Grose <fgrose@xxxxxxxxx>
• a problem when i use dm_io
  • From: "wzpywzh"<wzpywzh@xxxxxxx>
• Re: dm-mpath: Clear map_context pointer when requeuing
  • From: Hannes Reinecke <hare@xxxxxxx>
• dmraid ./dmraid.spec lib/device/scan.c tools/V ...
  • From: heinzm@xxxxxxxxxxxxxx
• Re: DM_snapshot_cow filesystem (dmsetup create snapshot)
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: DM_snapshot_cow filesystem (dmsetup create snapshot)
  • From: Douglas McClendon <dmc.lists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: DM_snapshot_cow filesystem (dmsetup create snapshot)
  • From: Douglas McClendon <dmc.lists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: DM_snapshot_cow filesystem (dmsetup create snapshot)
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: DM_snapshot_cow filesystem (dmsetup create snapshot)
  • From: Douglas McClendon <dmc.lists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: DM_snapshot_cow filesystem (dmsetup create snapshot)
  • From: Douglas McClendon <dmc.lists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: DM_snapshot_cow filesystem (dmsetup create snapshot)
  • From: Douglas McClendon <dmc.lists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: DM_snapshot_cow filesystem (dmsetup create snapshot)
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• [PATCH v3 4/4] scsi_dh: code cleanup and remove the references to scsi_dev_info
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• [PATCH v3 3/4] scsi_dh_rdac: Adding the match function for rdac device handler
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• [PATCH v3 2/4] scsi_dh_hp_sw: Adding the match function for hp_sw device handler
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• [PATCH v3 0/4] scsi_dh: Fix for handler attach and code clean up
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• [PATCH v3 1/4] scsi_dh_emc: Adding the match function for emc device handler
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Jan Kara <jack@xxxxxxx>
• Re: dm-mpath: Clear map_context pointer when requeuing
  • From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Jan Kara <jack@xxxxxxx>
• Re: [RESEND][PATCH 4/4] scsi_dh: code cleanup and remove the references to scsi_dev_info
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: [RESEND][PATCH 4/4] scsi_dh: code cleanup and remove the references to scsi_dev_info
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: DM_snapshot_cow filesystem (dmsetup create snapshot)
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: DM_snapshot_cow filesystem (dmsetup create snapshot)
  • From: Frederick Grose <fgrose@xxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Jan Kara <jack@xxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Kamal Mostafa <kamal@xxxxxxxxxxxxx>
• Re: DM_snapshot_cow filesystem (dmsetup create snapshot)
  • From: Douglas McClendon <dmc.lists@xxxxxxxxxxxxxxxxxxxxxx>
• Re: dm-mpath: Clear map_context pointer when requeuing
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH] dm-mpath: Clear map_context pointer when requeuing
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Jan Kara <jack@xxxxxxx>
• Re: [GIT PULL] Queue free fix (was Re: [PATCH] block: Free queue resources at blk_release_queue())
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH - v2] DM RAID: 'rebuild' parameter code should be setting MD_CHANGE_DEVS
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• Re: [GIT PULL] Queue free fix (was Re: [PATCH] block: Free queue resources at blk_release_queue())
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [RFC PATCH] block: change max_segments default to USHRT_MAX
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: info on enabling only one path with rdac and DS4700
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Eric Sandeen <sandeen@xxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Valerie Aurora <val@xxxxxxxxxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Jan Kara <jack@xxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Jan Kara <jack@xxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Jan Kara <jack@xxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Jan Kara <jack@xxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Jan Kara <jack@xxxxxxx>
• Re: info on enabling only one path with rdac and DS4700
  • From: Gianluca Cecchi <gianluca.cecchi@xxxxxxxxx>
• Re: DM_snapshot_cow filesystem (dmsetup create snapshot)
  • From: Frederick Grose <fgrose@xxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] DM RAID: Clean-up handling of 'rebuild' device requests
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• Re: info on enabling only one path with rdac and DS4700
  • From: Gianluca Cecchi <gianluca.cecchi@xxxxxxxxx>
• [PATCH] DM RAID: Clean-up handling of 'rebuild' device requests
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• Re: info on enabling only one path with rdac and DS4700
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: info on enabling only one path with rdac and DS4700
  • From: Gianluca Cecchi <gianluca.cecchi@xxxxxxxxx>
• Re: info on enabling only one path with rdac and DS4700
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: info on enabling only one path with rdac and DS4700
  • From: Gianluca Cecchi <gianluca.cecchi@xxxxxxxxx>
• Re: [PATCH] deadlock with suspend and quotas
  • From: Jan Kara <jack@xxxxxxx>
• Re: info on enabling only one path with rdac and DS4700
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: dm: fix discard support in dm_io
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: DM_snapshot_cow filesystem (dmsetup create snapshot)
  • From: Douglas McClendon <dmc.lists@xxxxxxxxxxxxxxxxxxxxxx>
• [UPDATED PATCH 57/62] dm: remove the second argument of k[un]map_atomic()
  • From: Cong Wang <amwang@xxxxxxxxxx>
• Re: [PATCH 17/62] md: remove the second argument of k[un]map_atomic()
  • From: Cong Wang <amwang@xxxxxxxxxx>
• Re: DM_snapshot_cow filesystem (dmsetup create snapshot)
  • From: Frederick Grose <fgrose@xxxxxxxxx>
• [PATCH 17/62] md: remove the second argument of k[un]map_atomic()
  • From: Cong Wang <amwang@xxxxxxxxxx>
• DM-Steg
  • From: Leo Samulis <anagon@xxxxxxxxx>
• Re: [PATCH 17/62] md: remove the second argument of k[un]map_atomic()
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: [PATCH 17/62] md: remove the second argument of k[un]map_atomic()
  • From: NeilBrown <neilb@xxxxxxx>
• [PATCH] deadlock with suspend and quotas
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH] dm: fix discard support in dm_io
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: libdevmapper
  • From: Busby <chaimvy@xxxxxxxxx>
• Re: info on enabling only one path with rdac and DS4700
  • From: Gianluca Cecchi <gianluca.cecchi@xxxxxxxxx>
• Re: [PATCH v2] dm: verity target
  • From: Mandeep Singh Baines <msb@xxxxxxxxxxxx>
• Re: raid1d crash at boot
  • From: Michał Mirosław <mirq-linux@xxxxxxxxxxxx>
• Re: raid1d crash at boot
  • From: Michał Mirosław <mirq-linux@xxxxxxxxxxxx>
• Re: raid1d crash at boot
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH 3/4] scsi_dh_rdac: Adding the match function for rdac device handler
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 3/4] scsi_dh_rdac: Adding the match function for rdac device handler
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: [PATCH 3/4] scsi_dh_rdac: Adding the match function for rdac device handler
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: info on enabling only one path with rdac and DS4700
  • From: Johannes Hirte <hirtejs@xxxxxxxxxxxxxxxxxx>
• Re: Bug#648367: device-mapper devices such as dm-crypt always have rotational=1; should inherit "rotational" setting from underlying devices
  • From: Josh Triplett <josh@xxxxxxxxxxxxxxxx>
• [PATCH] Update man page for multipath -r
  • From: Aruna Balakrishnaiah <aruna@xxxxxxxxxxxxxxxxxx>
• Re: info on enabling only one path with rdac and DS4700
  • From: Gianluca Cecchi <gianluca.cecchi@xxxxxxxxx>
• Re: info on enabling only one path with rdac and DS4700
  • From: Gianluca Cecchi <gianluca.cecchi@xxxxxxxxx>
• Re: [PATCH] multipath: rlookup WWIDs with spaces by alias
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: info on enabling only one path with rdac and DS4700
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: info on enabling only one path with rdac and DS4700
  • From: Johannes Hirte <hirtejs@xxxxxxxxxxxxxxxxxx>
• Re: Bug#648367: device-mapper devices such as dm-crypt always have rotational=1; should inherit "rotational" setting from underlying devices
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• libdevmapper
  • From: Yathindra <ydev@xxxxxxxxxxx>
• Re: info on enabling only one path with rdac and DS4700
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• info on enabling only one path with rdac and DS4700
  • From: Gianluca Cecchi <gianluca.cecchi@xxxxxxxxx>
• [PATCH] kpartx man page update
  • From: hegdevasant <vahegde1@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2] dm: verity target
  • From: Steffen Klassert <steffen.klassert@xxxxxxxxxxx>
• Re: Bug#648367: device-mapper devices such as dm-crypt always have rotational=1; should inherit "rotational" setting from underlying devices
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: Bug#648367: device-mapper devices such as dm-crypt always have rotational=1; should inherit "rotational" setting from underlying devices
  • From: Josh Triplett <josh@xxxxxxxxxxxxxxxx>
• Re: Bug#648367: device-mapper devices such as dm-crypt always have rotational=1; should inherit "rotational" setting from underlying devices
  • From: Ben Hutchings <ben@xxxxxxxxxxxxxxx>
• Re: [PATCH] multipath: rlookup WWIDs with spaces by alias
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• Re: [PATCH v2] dm: verity target
  • From: Mandeep Singh Baines <msb@xxxxxxxxxxxx>
• Re: [PATCH v2] dm: verity target
  • From: Steffen Klassert <steffen.klassert@xxxxxxxxxxx>
• Re: [PATCH] multipath: rlookup WWIDs with spaces by alias
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: Multipath.conf
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: [PATCH] multipath: rlookup WWIDs with spaces by alias
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: [PATCH] multipath: don't print so many add map messages
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: [PATCH] multipath: Set the default max_fds to the system max
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• [PATCH] multipath: don't print so many add map messages
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• [PATCH] multipath: Set the default max_fds to the system max
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• [PATCH] multipath: rlookup WWIDs with spaces by alias
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• [PATCH v2] dm: verity target
  • From: Mandeep Singh Baines <msb@xxxxxxxxxxxx>
• Multipath.conf
  • From: Tiago.Francisco.Abreu@xxxxxxxxxxxx
• Re: [PATCH] dm: verity target
  • From: Will Drewry <wad@xxxxxxxxxxxx>
• Re: [PATCH] dm: verity target
  • From: Steffen Klassert <steffen.klassert@xxxxxxxxxxx>
• device-mapper: table: 253:4: multipath: error attaching hardware handler
  • From: Harsha Sabbineni <harsha.kgp@xxxxxxxxx>
• [PATCH] dm: verity target
  • From: Mandeep Singh Baines <msb@xxxxxxxxxxxx>
• Re: [PATCH] Add missing break statement in kpartx.
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: Vendor/product comparisons are too broad
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Vendor/product comparisons are too broad
  • From: Anton Blanchard <anton@xxxxxxxxx>
• [ANNOUNCE] cryptsetup 1.4.1
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• i/o counting problems
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: turning the root volume into a snapshot stalls (ioctl hangs)
  • From: Hauke Laging <mailinglisten@xxxxxxxxxxxxxxx>
• Re: Error when compiling drivers/md/dm-bufio.c
  • From: Witold Baryluk <baryluk@xxxxxxxxxxxxxxxx>
• Re: Error when compiling drivers/md/dm-bufio.c
  • From: Witold Baryluk <baryluk@xxxxxxxxxxxxxxxx>
• Re: Error when compiling drivers/md/dm-bufio.c
  • From: Witold Baryluk <baryluk@xxxxxxxxxxxxxxxx>
• Re: turning the root volume into a snapshot stalls (ioctl hangs)
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• turning the root volume into a snapshot stalls (ioctl hangs)
  • From: Hauke Laging <mailinglisten@xxxxxxxxxxxxxxx>
• Re: [GIT PULL] Queue free fix (was Re: [PATCH] block: Free queue resources at blk_release_queue())
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Error when compiling drivers/md/dm-bufio.c
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [GIT PULL] Queue free fix (was Re: [PATCH] block: Free queue resources at blk_release_queue())
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Error when compiling drivers/md/dm-bufio.c
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: Error when compiling drivers/md/dm-bufio.c
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: Error when compiling drivers/md/dm-bufio.c
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: Error when compiling drivers/md/dm-bufio.c
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: multipath-tools/path_priority pp_alua/rtpg.c p ...
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• Re: Error when compiling drivers/md/dm-bufio.c
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Error when compiling drivers/md/dm-bufio.c
  • From: Witold Baryluk <baryluk@xxxxxxxxxxxxxxxx>
• [PATCH] dm-ioctl: Don't leak memory in target_message() if 'argc' is NULL
  • From: Jesper Juhl <jj@xxxxxxxxxxxxx>
• Re: HPA unlock during partition scan of RAID components
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• Re: HPA unlock during partition scan of RAID components
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: HPA unlock during partition scan of RAID components
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• Re: HPA unlock during partition scan of RAID components
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: HPA unlock during partition scan of RAID components
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• Re: HPA unlock during partition scan of RAID components
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: HPA unlock during partition scan of RAID components
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• Re: HPA unlock during partition scan of RAID components
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: HPA unlock during partition scan of RAID components
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• Re: Mapping sectors to have errors
  • From: Yathindra <ydev@xxxxxxxxxxx>
• Re: HPA unlock during partition scan of RAID components
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: HPA unlock during partition scan of RAID components
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• Re: HPA unlock during partition scan of RAID components
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [RESEND][PATCH 2/4] scsi_dh_hp_sw: Adding the match function for hp_sw device handler
  • From: Hannes Reinecke <hare@xxxxxxx>
• [RESEND][PATCH 2/4] scsi_dh_hp_sw: Adding the match function for hp_sw device handler
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: [RESEND][PATCH 2/4] scsi_dh_hp_sw: Adding the match function for hp_sw device handler
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• [PATCH] Add missing break statement in kpartx.
  • From: hegdevasant <vahegde1@xxxxxxxxxxxxxxxxxx>
• Re: [RESEND][PATCH 3/4] scsi_dh_rdac: Adding the match function for rdac device handler
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [RESEND][PATCH 4/4] scsi_dh: code cleanup and remove the references to scsi_dev_info
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [RESEND][PATCH 1/4] scsi_dh_emc: Adding the match function for emc device handler
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [RESEND][PATCH 2/4] scsi_dh_hp_sw: Adding the match function for hp_sw device handler
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: multipath-tools/path_priority pp_alua/rtpg.c p ...
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: multipath-tools/path_priority pp_alua/rtpg.c p ...
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• Re: HPA unlock during partition scan of RAID components
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: HPA unlock during partition scan of RAID components
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Cannot mount underlying block device after creating dm device.
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• Re: HPA unlock during partition scan of RAID components
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• Re: HPA unlock during partition scan of RAID components
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [RESEND][PATCH 3/4] scsi_dh_rdac: Adding the match function for rdac device handler
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• [RESEND][PATCH 2/4] scsi_dh_hp_sw: Adding the match function for hp_sw device handler
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• [RESEND][PATCH 1/4] scsi_dh_emc: Adding the match function for emc device handler
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• [RESEND][PATCH 0/4] scsi_dh: Fix for handler attach and code clean up
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• [RESEND][PATCH 4/4] scsi_dh: code cleanup and remove the references to scsi_dev_info
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: [PATCH 3/4] scsi_dh_rdac: Adding the match function for rdac device handler
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 3/4] scsi_dh_rdac: Adding the match function for rdac device handler
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Cannot mount underlying block device after creating dm device.
  • From: Sanjana <sanjana.linux@xxxxxxxxx>
• Re: multipath-tools/kpartx gpt.c
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: multipath-tools/path_priority pp_alua/rtpg.c p ...
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: [PATCH] scsi_dh_alua: Fix the time inteval for alua rtpgcommands
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: scsi_dh_rdac: Adding a device for rdac
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• scsi_dh_rdac: Adding a device for rdac
  • From: Daniel Lang <langd@xxxxxxxx>
• Re: scsi_dh_rdac: Add two new SUN devices to rdac_dev_list
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• scsi_dh_rdac: Add two new SUN devices to rdac_dev_list
  • From: Daniel Lang <langd@xxxxxxxx>
• Re: RFC: dm-switch target [v3]
  • From: <Jim_Ramsay@xxxxxxxx>
• Re: [PATCH 3/4] scsi_dh_rdac: Adding the match function for rdac device handler
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 3/4] scsi_dh_rdac: Adding the match function for rdac device handler
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: [PATCH 3/4] scsi_dh_rdac: Adding the match function for rdac device handler
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 3/4] scsi_dh_rdac: Adding the match function for rdac device handler
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: [PATCH 0/4] scsi_dh: Fix for handler attach and code clean up
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: creating two device mapper files for an underline blockdevice
  • From: Sanjana <sanjana.linux@xxxxxxxxx>
• Re: [git pull] device-mapper enhancements for 3.2
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: creating two device mapper files for an underline blockdevice
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: [PATCH 3/4] scsi_dh_rdac: Adding the match function for rdac device handler
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 0/4] scsi_dh: Fix for handler attach and code clean up
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [git pull] device-mapper enhancements for 3.2
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: creating two device mapper files for an underline blockdevice
  • From: Sanjana Shari <sanjana.linux@xxxxxxxxx>
• [PATCH 4/4] scsi_dh: code cleanup - remove the references to scsi_dev_info
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: creating two device mapper files for an underline blockdevice
  • From: Sanjana Shari <sanjana.linux@xxxxxxxxx>
• [PATCH 0/4] scsi_dh: Fix for handler attach and code clean up
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• [PATCH 1/4] scsi_dh_emc: Adding the match function for emc device handler
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• [PATCH 3/4] scsi_dh_rdac: Adding the match function for rdac device handler
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• [PATCH 2/4] scsi_dh_hp_sw: Adding the match function for hp_sw device handler
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: creating two device mapper files for an underline blockdevice
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: creating two device mapper files for an underline blockdevice
  • From: Sanjana Shari <sanjana.linux@xxxxxxxxx>
• creating two device mapper files for an underline blockdevice
  • From: Sanjana Shari <sanjana.linux@xxxxxxxxx>
• [git pull] device-mapper enhancements for 3.2
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [GIT PULL] Queue free fix (was Re: [PATCH] block: Free queue resources at blk_release_queue())
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: DM_snapshot_cow filesystem (dmsetup create snapshot)
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• DM_snapshot_cow filesystem (dmsetup create snapshot)
  • From: Mr Dash Four <mr.dash.four@xxxxxxxxxxxxxx>
• RHEL 6 I/O error messages during booting
  • From: Daniel Lang <langd@xxxxxxxx>
• Re: RHEL 6 I/O error messages during booting
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• RHEL 6 I/O error messages during booting
  • From: Daniel Lang <langd@xxxxxxxx>
• Re: Mapping sectors to have errors
  • From: Yathindra <ydev@xxxxxxxxxxx>
• Re: Mapping sectors to have errors
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: Mapping sectors to have errors
  • From: Yathindra <ydev@xxxxxxxxxxx>
• Re: DM inconsistent after disk migration
  • From: Bernd Broermann <bernd@xxxxxxxxxxxxx>
• Re: Mapping sectors to have errors
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Mapping sectors to have errors
  • From: Yathindra <ydev@xxxxxxxxxxx>
• multipath-tools libmultipath/config.c libmulti ...
  • From: bmarzins@xxxxxxxxxxxxxx
• Re: RFC: dm-switch target [v3]
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH] scsi_dh_alua: Fix the time inteval for alua rtpg commands
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• Re: [PATCH] scsi_dh: check queuedata pointer before proceeding further
  • From: Hannes Reinecke <hare@xxxxxxx>
• [ANNOUNCE] cryptsetup 1.4.0
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• [PATCH] scsi_dh: check queuedata pointer before proceeding further
  • From: "Moger, Babu" <Babu.Moger@xxxxxxxxxx>
• multipath-tools/libmultipath hwtable.c
  • From: bmarzins@xxxxxxxxxxxxxx
• multipath-tools/path_priority/pp_alua rtpg.c
  • From: bmarzins@xxxxxxxxxxxxxx
• [PATCH] check for mempool memory leaks
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH - v2] DM RAID: Use correct health status character when array is initializing and rebuilding devices
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• [PATCH 2 of 2 - v4] DM log userspace: Allow CTR devices response
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• [PATCHES] dm-crypt parallelization
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• multipath-tools/multipathd main.c
  • From: bmarzins@xxxxxxxxxxxxxx
• multipath-tools/multipath main.c
  • From: bmarzins@xxxxxxxxxxxxxx
• multipath-tools/path_priority pp_alua/rtpg.c p ...
  • From: bmarzins@xxxxxxxxxxxxxx
• multipath-tools/libmultipath callout.c
  • From: bmarzins@xxxxxxxxxxxxxx
• multipath-tools/kpartx gpt.c
  • From: bmarzins@xxxxxxxxxxxxxx
• Re: [Multipath] Round-robin performance limit
  • From: Pasi Kärkkäinen <pasik@xxxxxx>
• Re: Bisected: Massive memory leak in dm-snapshot in 3.1 development introduced
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: Bisected: Massive memory leak in dm-snapshot in 3.1 development introduced
  • From: Michael Leun <ml@xxxxxxxxxxxxxxx>
• Re: Bisected: Massive memory leak in dm-snapshot in 3.1 development introduced
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Bisected: Massive memory leak in dm-snapshot in 3.1 development introduced
  • From: Michael Leun <ml@xxxxxxxxxxxxxxx>
• Re: Bisected: Massive memory leak in dm-snapshot in 3.1 development introduced
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: Simulating faulty disk
  • From: Yathindra <ydev@xxxxxxxxxxx>
• Re: Simulating faulty disk
  • From: Yathindra <ydev@xxxxxxxxxxx>
• Re: Simulating faulty disk
  • From: Yathindra <ydev@xxxxxxxxxxx>
• Re: Simulating faulty disk
  • From: Yathindra <ydev@xxxxxxxxxxx>
• Re: RFC: dm-switch target [v2]
  • From: Pasi Kärkkäinen <pasik@xxxxxx>
• Re: [Multipath] Round-robin performance limit
  • From: Pasi Kärkkäinen <pasik@xxxxxx>
• RFC: dm-switch target [v3]
  • From: Jim Ramsay <jim_ramsay@xxxxxxxx>
• Re: [PATCH 1/2] [device-mapper] Document the fact that iterate_device method shouldn't block.
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [PATCH 2/2] [thin] in thin_iterate_devices(), get the pool dev size a non-blocking way.
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH 1/2] [device-mapper] Document the fact that iterate_device method shouldn't block.
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: Simulating faulty disk
  • From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
• Re: Simulating faulty disk
  • From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
• Re: Simulating faulty disk
  • From: Yathindra <ydev@xxxxxxxxxxx>
• Re: Simulating faulty disk
  • From: Yathindra <ydev@xxxxxxxxxxx>
• [PATCH 1/2] [device-mapper] Document the fact that iterate_device method shouldn't block.
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• [PATCH 2/2] [thin] in thin_iterate_devices(), get the pool dev size a non-blocking way.
  • From: Joe Thornber <ejt@xxxxxxxxxx>
• Re: Semaphore bug in dm-thin
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• [PATCH 2 of 2 - v3] DM log userspace: Allow CTR device respons
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• Semaphore bug in dm-thin
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: DM inconsistent after disk migration
  • From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
• DM inconsistent after disk migration
  • From: "Bernd Broermann" <bernd@xxxxxxxxxxxxx>
• Re: your mail
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: your mail
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• (no subject)
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH 2 of 2 - v2] DM log userspace: Allow CTR device response
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• [PATCH 1 of 2 - v2] DM log userspace: Minor fix-ups
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• Re: [RFC][PATCH] dm-cache (block level disk cache target): UPDATE
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 1 of 2] DM log userspace: Minor fix-ups
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• [RFC][PATCH] dm-cache (block level disk cache target): UPDATE
  • From: Stephen Bromfield <s.bromfield@xxxxxxxxx>
• Re: Getting dm extent mapping
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Getting dm extent mapping
  • From: markw@xxxxxxxxxxxxxx
• Re: [PATCH v2] dm mpath: maintain reference count for underlying devices
  • From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
• Re: [PATCH] multipath: handle offlined paths
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• [PATCH] multipath: handle offlined paths
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• Re: [PATCH v2] dm mpath: maintain reference count for underlying devices
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: dm-bufio
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: dm-bufio
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: dm-bufio
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH] dm-bufio
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• [PATCH] dm-bufio
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH 1/2] blk-flush: move the queue kick into blk_insert_cloned_request
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>