Linux Device-Mapper Development

• Thread Index

• [PATCH] DM RAID: add RAID1 support
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• [PATCH] DM RAID: do not print rebuilds in table line
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• [PATCH] DM RAID: allow metadata devices
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• multipatd -k "show config" related query....
  • From: Dharmesh Kamdar <kamdard71@xxxxxxxxx>
• Re: dm: Integrity errors should not cause failover
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: multipath produces a segmentation fault
  • From: "--[ UxBoD ]--" <uxbod@xxxxxxxxxxxx>
• Re: [PATCH] Fix a possible dm-kcopyd deadlock - preallocate sub jobs
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH] dm-io: reserve just one structure
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH] Remove the spinlock protecting the pages allocation
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: multipath produces a segmentation fault
  • From: "--[ UxBoD ]--" <uxbod@xxxxxxxxxxxx>
• multipath produces a segmentation fault
  • From: "--[ UxBoD ]--" <uxbod@xxxxxxxxxxxx>
• Re: dm snapshot diffs
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Issue occurred when fixed using mapped device and software RAID
  • From: "王道邦" <wangdb@xxxxxxxxxxxx>
• dm snapshot diffs
  • From: Groshev Dmitry <a2alt@xxxxx>
• Re: SUSE multipath-tools patch resync
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• [PATCH] Don't split SUB_JOB_SIZE jobs
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH] Remove the spinlock protecting the pages allocation
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH] dm-io: reserve just one bioset structure
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH] dm-io: reserve just one structure
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH] Reserve just one mempool entry
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• [PATCH] Fix a possible dm-kcopyd deadlock - preallocate sub jobs
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: 2.6.32.28 - md resync + pvmove - crash
  • From: Christian May <christian_may@xxxxxxxxxx>
• [PATCH] dm-io: flush CPU cache on vmalloc mappings
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• SUSE multipath-tools patch resync
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: dm: Integrity errors should not cause failover
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• FW: Buffer I/O error on access lun.....
  • From: Swastik Das <swastik.das@xxxxxxxxxxx>
• [PATCH] dm: Integrity errors should not cause failover
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• how to disable exclusive access
  • From: saeed bishara <saeed.bishara@xxxxxxxxx>
• Issue with dm snapshots
  • From: sdrb <sdrb@xxxxxxx>
• Re: dm-crypt on RAID5/6 write performance - cause & proposed solutions
  • From: Chris Lais <chris+linux@xxxxxxxxxxxxxx>
• Re: dm-crypt on RAID5/6 write performance - cause & proposed solutions
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• dm-crypt on RAID5/6 write performance - cause & proposed solutions
  • From: Chris Lais <chris+linux@xxxxxxxxxxxxxx>
• [PATCH] multipathd: Disassociate from /dev/console when daemonizing
  • From: Ankit Jain <jankit@xxxxxxx>
• Re: RHEL 6 I/O error messages during booting
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: RHEL 6 I/O error messages during booting
  • From: Malahal Naineni <malahal@xxxxxxxxxx>
• Re: RHEL 6 I/O error messages during booting
  • From: Chandra Seetharaman <sekharan@xxxxxxxxxx>
• Re: 2.6.32.28 - md resync + pvmove - crash
  • From: Christian May <christian_may@xxxxxxxxxx>
• Re: RHEL 6: Missing /dev/mpath directory
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• 2.6.32.28 - md resync + pvmove - crash
  • From: Nikola Ciprich <nikola.ciprich@xxxxxxxxxxx>
• Re: RHEL 6: Missing /dev/mpath directory
  • From: Gianluca Cecchi <gianluca.cecchi@xxxxxxxxx>
• Re: RHEL 6: Missing /dev/mpath directory
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• RHEL 6: Missing /dev/mpath directory
  • From: MOHAMMED FIRDOSH NASIM <firdosh.nasim@xxxxxxxxx>
• Re: RHEL 6 I/O error messages during booting
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• RHEL 6 I/O error messages during booting
  • From: Christian May <christian_may@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Lukas Czerner <lczerner@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Karel Zak <kzak@xxxxxxxxxx>
• SUSE multipath-tools resync
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH] multipathd: Don't mark a virtio_blk path offline if it has no sysfs "state" attribute
  • From: Martin Schwenke <martin@xxxxxxxxxx>
• [PATCH] Return PATH_UP for non-SCSI devices in path_offline()
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH] multipathd: Don't mark a virtio_blk path offline if it has no sysfs "state" attribute
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: [PATCH] multipathd: Don't mark a virtio_blk path offline if it has no sysfs "state" attribute
  • From: Hannes Reinecke <hare@xxxxxxx>
• [PATCH] multipathd: Don't mark a virtio_blk path offline if it has no sysfs "state" attribute
  • From: Martin Schwenke <martin@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• LinuxTag, Berlin, Weds 11 - Sat 14 May 2011
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Lukas Czerner <lczerner@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Lukas Czerner <lczerner@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Lukas Czerner <lczerner@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: "Ted Ts'o" <tytso@xxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Lukas Czerner <lczerner@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [Multipath] Round-robin performance limit
  • From: "John A. Sullivan III" <jsullivan@xxxxxxxxxxxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Lukas Czerner <lczerner@xxxxxxxxxx>
• Re: [Multipath] Round-robin performance limit
  • From: Malahal Naineni <malahal@xxxxxxxxxx>
• Re: [Multipath] Round-robin performance limit
  • From: "John A. Sullivan III" <jsullivan@xxxxxxxxxxxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Lukas Czerner <lczerner@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Lukas Czerner <lczerner@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Eric Sandeen <sandeen@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [Multipath] Round-robin performance limit
  • From: Adam Chasen <adam@xxxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Lukas Czerner <lczerner@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Lukas Czerner <lczerner@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [Multipath] Round-robin performance limit
  • From: Pasi Kärkkäinen <pasik@xxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Lukas Czerner <lczerner@xxxxxxxxxx>
• Re: [PATCH] workqueue: fix deadlock in worker_maybe_bind_and_lock()
  • From: "Rafael J. Wysocki" <rjw@xxxxxxx>
• Re: SAN failover question
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• SAN failover question
  • From: urgrue <urgrue@xxxxxxxxxxx>
• setting up dmraid event monitoring
  • From: "Sandra Escandor" <sescandor@xxxxxxxxxx>
• [PATCH] workqueue: fix deadlock in worker_maybe_bind_and_lock()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: Soft lockup during suspend since ~2.6.36 [bisected]
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Eric Sandeen <sandeen@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Lukas Czerner <lczerner@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Andreas Dilger <adilger.kernel@xxxxxxxxx>
• Re: Soft lockup during suspend since ~2.6.36 [bisected]
  • From: Thilo-Alexander Ginkel <thilo@xxxxxxxxxx>
• Re: [linux-lvm] do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [linux-lvm] do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Eric Sandeen <sandeen@xxxxxxxxxx>
• Re: [linux-lvm] do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Eric Sandeen <sandeen@xxxxxxxxxx>
• do not disable ext4 discards on first discard failure? [was: Re: dm snapshot: ignore discards issued to the snapshot-origin target]
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: DM RAID: add region_size param
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH] DM RAID: add write_mostly param
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• [PATCH] DM RAID: add region_size param
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• [Multipath] Round-robin performance limit
  • From: Adam Chasen <adam@xxxxxxxxxxx>
• Re: dm: allow a target to relax discard restrictions
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Soft lockup during suspend since ~2.6.36 [bisected]
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH] dm-thinp: report correct optimal I/O size
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [PATCH] dm-thinp: report correct optimal I/O size
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH] dm-thinp: report correct optimal I/O size
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [PATCH] dm: allow a target to relax discard restrictions
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [PATCH] dm snapshot: ignore discards issued to the snapshot-origin target
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: Soft lockup during suspend since ~2.6.36 [bisected]
  • From: Thilo-Alexander Ginkel <thilo@xxxxxxxxxx>
• [PATCH] dm snapshot: ignore discards issued to the snapshot-origin target
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH] dm: allow a target to relax discard restrictions
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH] multipath: clear checker message
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• [PATCH] multipath: clear checker message
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• Re: [PATCH] dm-thinp: report correct optimal I/O size
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH, RFC] dm: relax discard restrictions
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH, RFC] dm: relax discard restrictions
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• [PATCH] dm-thinp: report correct optimal I/O size
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [PATCH] dm-thinp: fix REQ_FLUSH semantics
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• what is the best configuration of NETAPP multipath
  • From: yue <ooolinux@xxxxxxx>
• Re: [PATCH] dm-thinp: fix REQ_FLUSH semantics
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: dm-thinp bug
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• [PATCH] dm-thinp: fix REQ_FLUSH semantics
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: dm-thinp bug
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: dm-thinp bug
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: dm-thinp bug
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: dm-thinp bug
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: dm-thinp bug
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: [PATCH] multipath: rename netapp.c to ontap.c
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• [PATCH] multipath: rename netapp.c to ontap.c
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• dm-thinp bug
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: dm snapshot: add discard support to the snapshot-origin target [was: Re: Testing TRIM with LVM]
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Soft lockup during suspend since ~2.6.36 [bisected]
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH] multipath: changes to NetApp's prioritizer
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: [PATCH] multipath: changes to NetApp's prioritizer
  • From: yue <ooolinux@xxxxxxx>
• Re: multipath failover & rhcs
  • From: John Ruemker <jruemker@xxxxxxxxxx>
• Re: [PATCH] multipath: changes to NetApp's prioritizer
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• [PATCH] multipath: changes to NetApp's prioritizer
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• [PATCH] multipath: recheck all priorities when a path comes back up
  • From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
• Re: [PATCH 1/3] scsi_dh_rdac : Add definitions for different RDAC operating modes
  • From: Mike Christie <michaelc@xxxxxxxxxxx>
• Re: [PATCH] multipathd: use 0 for initial pg if there are no priority groups
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• [PATCH] multipathd: use 0 for initial pg if there are no priority groups
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 3/3] scsi_dh_rdac : decide on whether to send mode select or not based on operating mode
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• Re: [PATCH 2/3] scsi_dh_rdac : Detect the different RDAC operating modes
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• Re: [PATCH 1/3] scsi_dh_rdac : Add definitions for different RDAC operating modes
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: "hch@xxxxxxxxxxxxx" <hch@xxxxxxxxxxxxx>
• Re: [PATCH] multipath-tools: Add new NEC diskarray to internal hardware table
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• [PATCH] multipath-tools: Add new NEC diskarray to internal hardware table
  • From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
• Re: RAID status, CSMI, and dmRAID
  • From: Juerg Haefliger <juergh@xxxxxxxxx>
• RAID status, CSMI, and dmRAID
  • From: "Sandra Escandor" <sescandor@xxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: "hch@xxxxxxxxxxxxx" <hch@xxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: "hch@xxxxxxxxxxxxx" <hch@xxxxxxxxxxxxx>
• Re: Soft lockup during suspend since ~2.6.36 [bisected]
  • From: Thilo-Alexander Ginkel <thilo@xxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: "hch@xxxxxxxxxxxxx" <hch@xxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Soft lockup during suspend since ~2.6.36 [bisected]
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: dm: improve block integrity support
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: "hch@xxxxxxxxxxxxx" <hch@xxxxxxxxxxxxx>
• Re: dm: improve block integrity support
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: dm: improve block integrity support
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• FW: creating a cascaded linear devices fails - please ignore previous mail
  • From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
• creating a cascaded linear devices fails
  • From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
• Re: dm snapshot: add discard support to the snapshot-origin target [was: Re: Testing TRIM with LVM]
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH] dm snapshot: add discard support to the snapshot-origin target [was: Re: Testing TRIM with LVM]
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: "hch@xxxxxxxxxxxxx" <hch@xxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: "hch@xxxxxxxxxxxxx" <hch@xxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: "hch@xxxxxxxxxxxxx" <hch@xxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: "hch@xxxxxxxxxxxxx" <hch@xxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: "hch@xxxxxxxxxxxxx" <hch@xxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: "hch@xxxxxxxxxxxxx" <hch@xxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: "hch@xxxxxxxxxxxxx" <hch@xxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: NeilBrown <neilb@xxxxxxx>
• multipath-tools/multipathd main.c
  • From: bmarzins@xxxxxxxxxxxxxx
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: "hch@xxxxxxxxxxxxx" <hch@xxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: NeilBrown <neilb@xxxxxxx>
• [PATCH 2/2] multipath-tools: report different piority value for rdac if io-shipping is enabled
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• [PATCH 1/2] multipath-tools: report PATH_UP for both path groups in rdac if io-shipping is enabled
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• [PATCH 1/1] multipath-tools: Set the rdac TAS bit if it changeable
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• [PATCH 3/3] scsi_dh_rdac : decide on whether to send mode select or not based on operating mode
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• [PATCH 1/3] scsi_dh_rdac : Add definitions for different RDAC operating modes
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• [PATCH 2/3] scsi_dh_rdac : Detect the different RDAC operating modes
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• [PATCH 0/3] scsi_dh_rdac : Support for io-shipping in LSI rdac storage
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• multipath-tools/kpartx kpartx.c
  • From: bmarzins@xxxxxxxxxxxxxx
• [PATCH] scsi_dh_rdac: Adding couple more vendor product ids
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• [ANNOUNCE] cryptsetup 1.3.0
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• multipath-tools/libmultipath config.c config.h ...
  • From: bmarzins@xxxxxxxxxxxxxx
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Please revert a91a2785b20
  • From: NeilBrown <neilb@xxxxxxx>
• IO errors when tuning max_sectors_kb value of a dm device
  • From: Grégoire Pichon <gregoire.pichon@xxxxxxxx>
• multipath-tools libmultipath/lock.h libmultipa ...
  • From: bmarzins@xxxxxxxxxxxxxx
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Amir Goldstein <amir73il@xxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Joel Becker <jlbec@xxxxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Joel Becker <jlbec@xxxxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Joel Becker <jlbec@xxxxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Mingming Cao <cmm@xxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Amir Goldstein <amir73il@xxxxxxxxx>
• [PATCH] dm: improve block integrity support
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: "Ted Ts'o" <tytso@xxxxxxx>
• Re: multipath -ll output discrepancy for IBM 1818 on SLES 11 SP1....
  • From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
• multipath -ll output discrepancy for IBM 1818 on SLES 11 SP1....
  • From: Dharmesh Kamdar <kamdard71@xxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Joel Becker <jlbec@xxxxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Matthew Wilcox <matthew@xxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Giridhar Malavali <giridhar.malavali@xxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Mingming Cao <cmm@xxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: <Shyam_Iyer@xxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Chris Mason <chris.mason@xxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Ric Wheeler <ricwheeler@xxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Theodore Tso <tytso@xxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Mingming Cao <cmm@xxxxxxxxxx>
• Re: Preliminary Agenda and Activities for LSF
  • From: <Shyam_Iyer@xxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Ric Wheeler <ricwheeler@xxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Jan Kara <jack@xxxxxxx>
• Re: Preliminary Agenda and Activities for LSF
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Preliminary Agenda and Activities for LSF
  • From: <Shyam_Iyer@xxxxxxxx>
• Re: Preliminary Agenda and Activities for LSF
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: <Shyam_Iyer@xxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: dm table: Reject unconfigured device
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: dm table: Reject unconfigured device
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: <Shyam_Iyer@xxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: dm-ioband max-bw and min-bw
  • From: Степан Фёдоров <stepan.fedorov@xxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: <Shyam_Iyer@xxxxxxxx>
• [PATCH] dm table: Reject unconfigured device
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Need to refactor DM's integrity profile support a bit (was: Re: Please revert a91a2785b20)
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Please revert a91a2785b20
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: James Bottomley <James.Bottomley@xxxxxxx>
• Re: Please revert a91a2785b20
  • From: James Bottomley <James.Bottomley@xxxxxxx>
• Re: Please revert a91a2785b20
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Ric Wheeler <ricwheeler@xxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Matthew Wilcox <matthew@xxxxxx>
• Re: [Lsf] Preliminary Agenda and Activities for LSF
  • From: Ric Wheeler <rwheeler@xxxxxxxxxx>
• Re: dm mpath: integrity errors should not cause failover
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: dm mpath: integrity errors should not cause failover
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH] dm mpath: integrity errors should not cause failover
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• mirror target memory consumption
  • From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
• RFC: dm-switch target
  • From: "Jason Shamberger" <Jason_Shamberger@xxxxxxxx>
• Re: Differentiating between dm devices
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• [git pull] device-mapper patches for 2.6.39
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: Differentiating between dm devices
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: Differentiating between dm devices
  • From: Hannes Reinecke <hare@xxxxxxx>
• UUID homogenization
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• Differentiating between dm devices
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• dm-ioband max-bw and min-bw
  • From: Степан Фёдоров <stepan.fedorov@xxxxxxxx>
• difference in running multipathd in console versus cron
  • From: Bart Coninckx <bart.coninckx@xxxxxxxxxx>
• multipath-tools and IBM 2810 XIV
  • From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
• mirror target memory consumption
  • From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
• Re: FW: the mirror log is NOT kept on disk
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• FW: the mirror log is NOT kept on disk
  • From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
• the mirror log is NOT kept on disk
  • From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
• multipath-tools libmultipath/dict.c libmultipa ...
  • From: bmarzins@xxxxxxxxxxxxxx
• orphan status and mixed pvs
  • From: "Janec, Jozef" <jozef.janec@xxxxxx>
• Re: [RFC][PATCH] dm: improve read performance
  • From: Nikanth Karthikesan <knikanth@xxxxxxx>
• Re: [PATCH] Fix over-zealous flush_disk when changing device size.
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: [Drbd-dev] [PATCH 2/2 v2] netlink: kill eff_cap from struct netlink_skb_parms
  • From: Evgeniy Polyakov <zbr@xxxxxxxxxxx>
• Re: [PATCH v2] dm-throttle: new device mapper target to throttle reads and writes
  • From: Vivek Goyal <vgoyal@xxxxxxxxxx>
• Re: [RFC][PATCH] dm: improve read performance
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• multipath performance problem
  • From: Leonid Podolny <leonid.podolny@xxxxxxxxxxx>
• Re: [PATCH v2] dm-throttle: new device mapper target to throttle reads and writes
  • From: Juerg Haefliger <juergh@xxxxxxxxx>
• Re: [RFC][PATCH] dm: improve read performance
  • From: Nikanth Karthikesan <knikanth@xxxxxxx>
• Re: [PATCH] Fix over-zealous flush_disk when changing device size.
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] Fix over-zealous flush_disk when changing device size.
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• [PATCH v4] dm stripe: implement merge method
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH 04/13] dm: use list_move() instead of list_del()/list_add() combination
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: [PATCH v3] dm stripe: implement merge method
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• shared snapshot LVM patch compile error
  • From: devicemapper niko <devicemapper.niko@xxxxxxxxx>
• Re: [PATCH v3] dm stripe: implement merge method
  • From: Mustafa Mesanovic <mume@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v3] dm stripe: implement merge method
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH] block: Require subsystems to explicitly allocate bio_set integrity mempool
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: [PATCH] block: Require subsystems to explicitly allocate bio_set integrity mempool (was: Re: mirrored device with thousand of mappingtableentries)
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [patch] Add MD36xxf into RDAC device list
  • From: <Yanqing_Liu@xxxxxxxx>
• [MULTIPATH] Help to understand some points
  • From: Guillaume Camera <camera.g@xxxxxxxxx>
• Re: mirrored device with thousand of mappingtableentries
  • From: "Martin K. Petersen" <mkp@xxxxxxx>
• Re: generic wrappers for multi-device FS operations
  • From: Ric Wheeler <ricwheeler@xxxxxxxxx>
• Re: generic wrappers for multi-device FS operations
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [PATCH v3] dm stripe: implement merge method
  • From: Mustafa Mesanovic <mume@xxxxxxxxxxxxxxxxxx>
• Re: generic wrappers for multi-device FS operations
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: [PATCH 05/10] block: remove per-queue plugging
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: generic wrappers for multi-device FS operations
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: generic wrappers for multi-device FS operations
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• [PATCH] Wipe buffer even if vamlloc fails
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: generic wrappers for multi-device FS operations
  • From: Ric Wheeler <ricwheeler@xxxxxxxxx>
• Re: generic wrappers for multi-device FS operations
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: generic wrappers for multi-device FS operations
  • From: Wendy Cheng <s.wendy.cheng@xxxxxxxxx>
• Re: How does dm-thinp handle the our of space error?
  • From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
• dmsetup do not know sda*
  • From: yue <ooolinux@xxxxxxx>
• How does dm-thinp handle the our of space error?
  • From: Xie Gang <xiegang112@xxxxxxxxx>
• Re: generic wrappers for multi-device FS operations
  • From: Dave Chinner <david@xxxxxxxxxxxxx>
• Re: generic wrappers for multi-device FS operations
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: generic wrappers for multi-device FS operations
  • From: Ric Wheeler <ricwheeler@xxxxxxxxx>
• Re: generic wrappers for multi-device FS operations
  • From: Andreas Dilger <adilger@xxxxxxxxx>
• Re: generic wrappers for multi-device FS operations
  • From: Lars Marowsky-Bree <lmb@xxxxxxxxxx>
• [PATCH] Fix using of possible uninitialised params struct (secure flag)
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: [Drbd-dev] [PATCH 2/2 v2] netlink: kill eff_cap from struct netlink_skb_parms
  • From: Patrick McHardy <kaber@xxxxxxxxx>
• Re: generic wrappers for multi-device FS operations
  • From: Ric Wheeler <ricwheeler@xxxxxxxxx>
• Re: generic wrappers for multi-device FS operations
  • From: Ric Wheeler <ricwheeler@xxxxxxxxx>
• Re: generic wrappers for multi-device FS operations
  • From: James Bottomley <James.Bottomley@xxxxxxx>
• Re: generic wrappers for multi-device FS operations
  • From: Josef Bacik <josef@xxxxxxxxxx>
• Re: [Drbd-dev] [PATCH 2/2 v2] netlink: kill eff_cap from struct netlink_skb_parms
  • From: Evgeniy Polyakov <zbr@xxxxxxxxxxx>
• Re: generic wrappers for multi-device FS operations
  • From: Ric Wheeler <ricwheeler@xxxxxxxxx>
• Re: generic wrappers for multi-device FS operations
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: mirrored device with thousand of mappingtableentries
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• generic wrappers for multi-device FS operations
  • From: Ric Wheeler <ricwheeler@xxxxxxxxx>
• Re: [PATCH v3] dm stripe: implement merge method
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: dm: Integrity errors should not cause failover
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: dm: Integrity errors should not cause failover
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: dm: Integrity errors should not cause failover
  • From: James Bottomley <James.Bottomley@xxxxxxx>
• Re: dm: Integrity errors should not cause failover
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [Drbd-dev] [PATCH 2/2 v2] netlink: kill eff_cap from struct netlink_skb_parms
  • From: Patrick McHardy <kaber@xxxxxxxxx>
• Re: [PATCH v3] dm stripe: implement merge method
  • From: Mustafa Mesanovic <mume@xxxxxxxxxxxxxxxxxx>
• Re: multipath-tools multipath.conf.synthetic
  • From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
• [PATCH] dm: Integrity errors should not cause failover
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: mirrored device with thousand of mappingtableentries
  • From: "Martin K. Petersen" <mkp@xxxxxxx>
• [PATCH v3] dm stripe: implement merge method
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH] Fix over-zealous flush_disk when changing device size.
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] multipath: Retry host transient errors for rdac checker
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: [PATCH] Fix over-zealous flush_disk when changing device size.
  • From: James Bottomley <James.Bottomley@xxxxxxx>
• Re: [PATCH] Fix over-zealous flush_disk when changing device size.
  • From: NeilBrown <neilb@xxxxxxx>
• Re: mirrored device with thousand of mappingtableentries
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: mirrored device with thousand of mappingtableentries
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• multipath-tools multipath.conf.synthetic
  • From: bmarzins@xxxxxxxxxxxxxx
• Re: [PATCH] Fix over-zealous flush_disk when changing device size.
  • From: James Bottomley <James.Bottomley@xxxxxxx>
• Re: mirrored device with thousand of mappingtableentries
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• multipath-tools/libmultipath discovery.c
  • From: bmarzins@xxxxxxxxxxxxxx
• Re: mirrored device with thousand of mappingtableentries
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: [RFC][PATCH] dm: improve read performance
  • From: Mustafa Mesanovic <mume@xxxxxxxxxxxxxxxxxx>
• multipath-tools ./multipath.conf.defaults kpar ...
  • From: bmarzins@xxxxxxxxxxxxxx
• Re: [PATCH] Fix over-zealous flush_disk when changing device size.
  • From: Andrew Patterson <andrew.patterson@xxxxxx>
• Re: mirrored device with thousand of mappingtableentries
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: mirrored device with thousand of mappingtableentries
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: [PATCH] Fix over-zealous flush_disk when changing device size.
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
  • From: Charles Slivkoff <slivkoff@xxxxxxx>
• Re: [PATCH] Fix over-zealous flush_disk when changing device size.
  • From: Andrew Patterson <andrew.patterson@xxxxxx>
• Re: [Drbd-dev] [PATCH 2/2 v2] netlink: kill eff_cap from struct netlink_skb_parms
  • From: Evgeniy Polyakov <zbr@xxxxxxxxxxx>
• Re: Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• Re: [Drbd-dev] [PATCH 2/2 v2] netlink: kill eff_cap from struct netlink_skb_parms
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] Fix over-zealous flush_disk when changing device size.
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [Drbd-dev] [PATCH 2/2 v2] netlink: kill eff_cap from struct netlink_skb_parms
  • From: Chris Wright <chrisw@xxxxxxxxxxxx>
• Re: [Drbd-dev] [PATCH 2/2 v2] netlink: kill eff_cap from struct netlink_skb_parms
  • From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
• Re: [PATCH 2/2 v2] netlink: kill eff_cap from struct netlink_skb_parms
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
  • From: Charles Slivkoff <slivkoff@xxxxxxx>
• [RFC PATCH 4/2] connector: update callbacks to use security_netlink_recv()
  • From: Chris Wright <chrisw@xxxxxxxxxxxx>
• [RFC PATCH 3/2] security: update security_netlink_recv hook prototype
  • From: Chris Wright <chrisw@xxxxxxxxxxxx>
• Re: [PATCH 2/2] netlink: kill eff_cap from struct netlink_skb_parms
  • From: Chris Wright <chrisw@xxxxxxxxxxxx>
• [PATCH 2/2 v2] netlink: kill eff_cap from struct netlink_skb_parms
  • From: Chris Wright <chrisw@xxxxxxxxxxxx>
• Re: [PATCH 2/2] netlink: kill eff_cap from struct netlink_skb_parms
  • From: James Morris <jmorris@xxxxxxxxx>
• Re: [PATCH 2/2] netlink: kill eff_cap from struct netlink_skb_parms
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Dell MD3200 - sd: Current: sense key: Illegal
  • From: <Yanqing_Liu@xxxxxxxx>
• Re: [PATCH 2/2] netlink: kill eff_cap from struct netlink_skb_parms
  • From: Chris Wright <chrisw@xxxxxxxxxxxx>
• Re: Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
  • From: <Menny_Hamburger@xxxxxxxx>
• Re: Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
  • From: Charles Slivkoff <slivkoff@xxxxxxx>
• Re: [PATCH] Fix over-zealous flush_disk when changing device size.
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: Huge memory allocation
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• [PATCH 2/2] netlink: kill eff_cap from struct netlink_skb_parms
  • From: Patrick McHardy <kaber@xxxxxxxxx>
• Re: Huge memory allocation
  • From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
• Re: Huge memory allocation
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Can I add an extent to en existing linear table?
  • From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
• Re: Huge memory allocation
  • From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
• Re: Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• Re: Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
  • From: Charles Slivkoff <slivkoff@xxxxxxx>
• Re: Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• Re: Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
  • From: Charles Slivkoff <slivkoff@xxxxxxx>
• Re: Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• How to change the size of a snapshot device?
  • From: Greg Stark <stark@xxxxxxx>
• How to resize a snapshot to hold a larger filesystem
  • From: Greg Stark <stark@xxxxxxx>
• [PATCH] multipath: Retry host transient errors for rdac checker
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• Dell MD3200 - sd: Current: sense key: Illegal Request ASC=0x94 ASCQ=0x1ASC=0x94 ASCQ=0x1
  • From: Charles Slivkoff <slivkoff@xxxxxxx>
• Re: Huge memory allocation
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Huge memory allocation
  • From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
• Re: clustered snapshots status, LVM on shared storage without CLVM?
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• clustered snapshots status, LVM on shared storage without CLVM?
  • From: Nikola Ciprich <extmaillist@xxxxxxxxxxx>
• Re: mirrored device with thousand of mappingtableentries
  • From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
• Re: mirrored device with thousand of mappingtableentries
  • From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
• Re: mirrored device with thousand of mappingtableentries
  • From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
• Re: mirrored device with thousand of mappingtableentries
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: mirrored device with thousand of mappingtableentries
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: mirrored device with thousand of mappingtableentries
  • From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
• Re: mirrored device with thousand of mappingtableentries
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: mirrored device with thousand of mappingtableentries
  • From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
• Re: mirrored device with thousand of mapping tableentries
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: mirrored device with thousand of mapping tableentries
  • From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
• Re: mirrored device with thousand of mapping table entries
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• mirrored device with thousand of mapping table entries
  • From: "Eli Malul" <eli.malul@xxxxxxxxxxxxx>
• Re: [PATCH 1/1] RFC: scsi/dm-mpath: return -EACCES on reservation conflict
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 1/1] RFC: scsi/dm-mpath: return -EACCES on reservation conflict
  • From: Eddie Williams <Eddie.Williams@xxxxxxxxxxx>
• Re: [PATCH 1/1] RFC: scsi/dm-mpath: return -EACCES on reservation conflict
  • From: Eddie Williams <Eddie.Williams@xxxxxxxxxxx>
• Re: call for slideware ;)
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: call for slideware ;)
  • From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
• Re: call for slideware ;)
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: call for slideware ;)
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: call for slideware ;)
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Where can I get thin provisioning target sources?
  • From: xiaoli zhu <xiao001li@xxxxxxxxx>
• Re: [PATCH] Fix over-zealous flush_disk when changing device size.
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] Fix over-zealous flush_disk when changing device size.
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• dm_mod crashed while adding new luns into multipath
  • From: "Janec, Jozef" <jozef.janec@xxxxxx>
• Re: What is the deal with the partition separator?
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• multipath-tools ./multipath.conf.annotated lib ...
  • From: bmarzins@xxxxxxxxxxxxxx
• Re: timestamp for shared snapshot
  • From: devicemapper niko <devicemapper.niko@xxxxxxxxx>
• Re: Improving dm-mirror as a final year project
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• Re: [PATCH] Fix over-zealous flush_disk when changing device size.
  • From: Jeff Moyer <jmoyer@xxxxxxxxxx>
• Re: What is the deal with the partition separator?
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: What is the deal with the partition separator?
  • From: Curtis Gedak <gedakc@xxxxxxxxx>
• Re: What is the deal with the partition separator?
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: What is the deal with the partition separator?
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• Re: What is the deal with the partition separator?
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: What is the deal with the partition separator?
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• Linux DMM Questions
  • From: "CHANDRASEKARAN, GIRIDHAR (GIRI) (ATTSI)" <gs3162@xxxxxxx>
• Re: Improving dm-mirror as a final year project
  • From: Miklos Vajna <vmiklos@xxxxxx>
• Re: What is the deal with the partition separator?
  • From: Hannes Reinecke <hare@xxxxxxx>
• [PATCH] Fix over-zealous flush_disk when changing device size.
  • From: NeilBrown <neilb@xxxxxxx>
• Re: What is the deal with the partition separator?
  • From: Curtis Gedak <gedakc@xxxxxxxxx>
• Re: What is the deal with the partition separator?
  • From: Curtis Gedak <gedakc@xxxxxxxxx>
• Re: What is the deal with the partition separator?
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• Re: What is the deal with the partition separator?
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• multipath-tools/libmultipath configure.c struc ...
  • From: bmarzins@xxxxxxxxxxxxxx
• Re: timestamp for shared snapshot
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• [PATCH] Use only specific errors when failing dm-ioctl
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: Improving dm-mirror as a final year project
  • From: Miklos Vajna <vmiklos@xxxxxx>
• Re: timestamp for shared snapshot
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• timestamp for shared snapshot
  • From: devicemapper niko <devicemapper.niko@xxxxxxxxx>
• Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: What is the deal with the partition separator?
  • From: Hannes Reinecke <hare@xxxxxxx>
• What is the deal with the partition separator?
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• Re: Improving dm-mirror as a final year project
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH] Return EROFS if read-only detected on block device
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• [PATCH] Propagate device open error to table constructor.
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• [PATCH] Do not open log and cow device read-write for read-only mappings
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: Improving dm-mirror as a final year project
  • From: Miklos Vajna <vmiklos@xxxxxx>
• Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
  • From: NeilBrown <neilb@xxxxxxx>
• Re: Improving dm-mirror as a final year project
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• Re: Improving dm-mirror as a final year project
  • From: Miklos Vajna <vmiklos@xxxxxx>
• Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH] loop: clear read-only flag in loop_clr_fd.
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: [PATCH] loop: clear read-only flag in loop_clr_fd.
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• What is the status of RAID5 support with pdc (AMD SB850 Southbridge) hardware? dmraid -rD output
  • From: "rkliese@xxxxxx" <rkliese@xxxxxx>
• Re: multipath: partitions are not created on IBM 1746 (SAS connection to DS3512)
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: multipath: partitions are not created on IBM 1746 (SAS connection to DS3512)
  • From: Peter Volkov <peter.volkov@xxxxxxxxx>
• [PATCH v2] scsi_dh_rdac : Adding MODULE VERSION for rdac device handler
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• [PATCH v2] [SCSI] fix kzalloc in scsi device handler
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• [PATCH} scsi_dh_rdac: fix for lun_table update for rdac device handler
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• Re: [RFC PATCH] multipathd: use 0 for initial pg if nr_priority_groups=0
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [RFC PATCH] multipathd: use 0 for initial pg if nr_priority_groups=0
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 2/2 v2] dm mpath: allow table load with 0 priority groups
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH 2/2 v2] dm mpath: allow table load with 0 priority groups
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: dd slow while reading on multipathing, writing is fast
  • From: Bart Coninckx <bart.coninckx@xxxxxxxxxx>
• [PATCH]: multipath: fail path on zero size devices
  • From: <Menny_Hamburger@xxxxxxxx>
• Re: multipath: rdac on IBM 1746 (SAS connection to DS3512)
  • From: Malahal Naineni <malahal@xxxxxxxxxx>
• Re: Improving dm-mirror as a final year project
  • From: Miklos Vajna <vmiklos@xxxxxx>
• Re: dd slow while reading on multipathing, writing is fast
  • From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
• Re: dd slow while reading on multipathing, writing is fast
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• multipath: rdac on IBM 1746 (SAS connection to DS3512)
  • From: Peter Volkov <peter.volkov@xxxxxxxxx>
• dd slow while reading on multipathing, writing is fast
  • From: bart.coninckx@xxxxxxxxxx
• Re: multipath: rdac on IBM 1746 (SAS connection to DS3512)
  • From: Peter Volkov <peter.volkov@xxxxxxxxx>
• Re: multipath: rdac on IBM 1746 (SAS connection to DS3512)
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: [PATCH 1/3] dm crypt: wipe keys string immediately after key is set
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 3/3] dm ioctl: add data secure (bufer wipe) flag
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 2/3] dm ioctl: tidy code for next change
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH]: scsi_dh_rdac: fix BUG_ON in get_rdac_data from within send_mode_select
  • From: <Menny_Hamburger@xxxxxxxx>
• Re: Using the dm tools to create a writable "mirror" of a physical disk
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• [PATCH 3/3] dm ioctl: add data secure (bufer wipe) flag
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• [PATCH 2/3] dm ioctl: tidy code for next change
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• [PATCH 1/3] dm crypt: wipe keys string immediately after key is set
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Using the dm tools to create a writable "mirror" of a physical disk
  • From: Anders Andersson <pipatron@xxxxxxxxx>
• [PATCH] add -r to make resulting device read-only
  • From: Ritesh Raj Sarraf <rrs@xxxxxxxxxxxxxx>
• Re: [PATCH]: scsi_dh_rdac: fix BUG_ON in get_rdac_data from within send_mode_select
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• Re: Improving dm-mirror as a final year project
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• Re: [PATCH 2/2] dm mpath: allow table load with 0 priority groups
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [RFC PATCH] multipathd: use 0 for initial pg if nr_priority_groups=0
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: Possible severe bug in the device mapper?
  • From: Andreas Heinlein <aheinlein@xxxxxxx>
• Re: Possible severe bug in the device mapper?
  • From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
• Re: Possible severe bug in the device mapper?
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: multipath: change the DEFAULT_MINIO for the request based multipath
  • From: Malahal Naineni <malahal@xxxxxxxxxx>
• Re: Possible severe bug in the device mapper?
  • From: Andreas Heinlein <aheinlein@xxxxxxx>
• Re: multipath: change the DEFAULT_MINIO for the request based multipath
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: multipath: change the DEFAULT_MINIO for the request based multipath
  • From: Malahal Naineni <malahal@xxxxxxxxxx>
• Re: multipath: change the DEFAULT_MINIO for the request based multipath
  • From: Malahal Naineni <malahal@xxxxxxxxxx>
• Re: [PATCH]: scsi_dh_rdac: fix BUG_ON in get_rdac_data from within send_mode_select
  • From: <Menny_Hamburger@xxxxxxxx>
• Re: multipath: change the DEFAULT_MINIO for the request based multipath
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: multipath: change the DEFAULT_MINIO for the request based multipath
  • From: Malahal Naineni <malahal@xxxxxxxxxx>
• Re: multipath: change the DEFAULT_MINIO for the request based multipath
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: [PATCH]: scsi_dh_rdac: fix BUG_ON in get_rdac_data from within send_mode_select
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• [RFC PATCH] multipathd: use 0 for initial pg if nr_priority_groups=0 (was: Re: [PATCH 2/2] dm mpath: allow table load with 0 priority groups)
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH 2/2] dm mpath: allow table load with 0 priority groups
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• [PATCH 2/2] dm mpath: allow table load with 0 priority groups
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH 1/2] dm mpath: fail message ioctl if specified path is not valid
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: Possible severe bug in the device mapper?
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: Possible severe bug in the device mapper?
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Possible severe bug in the device mapper?
  • From: Andreas Heinlein <aheinlein@xxxxxxx>
• Re: How to test the read/write flow of dm-target.
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: How to test the read/write flow of dm-target.
  • From: nishant mungse <nishantmungse@xxxxxxxxx>
• [PATCH]: scsi_dh_rdac: fix BUG_ON in get_rdac_data from within send_mode_select
  • From: <Menny_Hamburger@xxxxxxxx>
• How to find last sector of bio.
  • From: nishant mungse <nishantmungse@xxxxxxxxx>
• Re: How to test the read/write flow of dm-target.
  • From: Malahal Naineni <malahal@xxxxxxxxxx>
• Re: Doubt regarding dm-raid1
  • From: Malahal Naineni <malahal@xxxxxxxxxx>
• Doubt regarding dm-raid1
  • From: nishant mungse <nishantmungse@xxxxxxxxx>
• How to test the read/write flow of dm-target.
  • From: nishant mungse <nishantmungse@xxxxxxxxx>
• Re: multipath: change the DEFAULT_MINIO for the request based multipath
  • From: nishant mungse <nishantmungse@xxxxxxxxx>
• Re: Improving dm-mirror as a final year project
  • From: nishant mungse <nishantmungse@xxxxxxxxx>
• Re: Improving dm-mirror as a final year project
  • From: Malahal Naineni <malahal@xxxxxxxxxx>
• Re: multipath: change the DEFAULT_MINIO for the request based multipath
  • From: nishant mungse <nishantmungse@xxxxxxxxx>
• Re: Improving dm-mirror as a final year project
  • From: nishant mungse <nishantmungse@xxxxxxxxx>
• Improving dm-mirror as a final year project
  • From: Miklos Vajna <vmiklos@xxxxxxxxxxxxxx>
• Re: Announcement: new device-mapper thin provisioning target with infrastructure online for review
  • From: Joe Thornber <thornber@xxxxxxxxxx>
• Re: multipath: change the DEFAULT_MINIO for the request based multipath
  • From: Malahal Naineni <malahal@xxxxxxxxxx>
• Improving dm-mirror as a final year project
  • From: Miklos Vajna <vmiklos@xxxxxxxxxxxxxx>
• Re: Announcement: new device-mapper thin provisioning target with infrastructure online for review
  • From: Phillip Susi <psusi@xxxxxxxxxx>
• Announcement: new device-mapper thin provisioning target with infrastructure online for review
  • From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
• Re: [PATCH wq#for-2.6.38] workqueue: use WQ_MEM_RECLAIM instead of WQ_RESCUER
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: multipath: change the DEFAULT_MINIO for the request based multipath
  • From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
• Re: multipath - reference count on pgpath
  • From: "Moger, Babu" <Babu.Moger@xxxxxxx>
• Re: multipath - reference count on pgpath
  • From: <Menny_Hamburger@xxxxxxxx>
• Re: [PATCH] multipath: reference count on pgpath
  • From: <Menny_Hamburger@xxxxxxxx>
• [PATCH] multipath: reference count on pgpath
  • From: <Menny_Hamburger@xxxxxxxx>
• multipath - reference count on pgpath
  • From: <Menny_Hamburger@xxxxxxxx>
• Re: multipath: change the DEFAULT_MINIO for the request based multipath
  • From: Malahal Naineni <malahal@xxxxxxxxxx>
• multipath-tools ./multipath.conf.defaults libm ...
  • From: bmarzins@xxxxxxxxxxxxxx
• Re: multipath: change the DEFAULT_MINIO for the request based multipath
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: multipath: change the DEFAULT_MINIO for the request based multipath
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: multipath: change the DEFAULT_MINIO for the request based multipath
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: multipath: change the DEFAULT_MINIO for the request based multipath
  • From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
• Re: multipath: change the DEFAULT_MINIO for the request based multipath
  • From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
• Re: multipath: change the DEFAULT_MINIO for the request based multipath
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH] [RFC] multipath: change the DEFAULT_MINIO for the request based multipath
  • From: Hannes Reinecke <hare@xxxxxxx>
• [PATCH] [RFC] multipath: change the DEFAULT_MINIO for the request based multipath
  • From: Malahal Naineni <malahal@xxxxxxxxxx>
• Re: [PATCH 14/49] drivers/md: Use vzalloc
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: help:"event number"
  • From: tom z <maillist.tom@xxxxxxxxx>
• Re: help:"event number"
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• help:"event number"
  • From: tom z <maillist.tom@xxxxxxxxx>
• Re: [PATCH UPDATED] block: restore multiple bd_link_disk_holder() support
  • From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
• Re: [PATCH UPDATED] block: restore multiple bd_link_disk_holder() support
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: "Ted Ts'o" <tytso@xxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• [PATCH UPDATED] block: restore multiple bd_link_disk_holder() support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Kay Sievers <kay.sievers@xxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Karel Zak <kzak@xxxxxxxxxx>
• Re: training mpath to discern between SCSI errors
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: What is the status of RAID5 support with pdc (AMD SB850 Southbridge) hardware?
  • From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
• Re: [PATCH] block: restore multiple bd_link_disk_holder() support
  • From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
• Re: training mpath to discern between SCSI errors
  • From: Hannes Reinecke <hare@xxxxxxx>
• Re: [RFC PATCH 0/3] differentiate between I/O errors
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: training mpath to discern between SCSI errors
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: [PATCH] Documentation: dm-crypt: update cryptsetup homepage
  • From: Jiri Kosina <jkosina@xxxxxxx>
• [PATCH] Documentation: dm-crypt: update cryptsetup homepage
  • From: Andrea Gelmini <andrea.gelmini@xxxxxxxxx>
• Re: [PATCH] Documentation: dm-crypt: update cryptsetup homepage
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: "Ted Ts'o" <tytso@xxxxxxx>
• [git pull] device-mapper patches for 2.6.38
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: NeilBrown <neilb@xxxxxxx>
• Re: [PATCH] block: restore multiple bd_link_disk_holder() support
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• [PATCH] block: restore multiple bd_link_disk_holder() support
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Kay Sievers <kay.sievers@xxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Karel Zak <kzak@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Kay Sievers <kay.sievers@xxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Theodore Tso <tytso@xxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Karel Zak <kzak@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Karel Zak <kzak@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
• Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• Re: linux-next: Tree for January 12 (dm-crypt)
  • From: Alasdair G Kergon <agk@xxxxxxxxxx>
• What is the status of RAID5 support with pdc (AMD SB850 Southbridge) hardware?
  • From: Mantas Kriaučiūnas <mantas@xxxxxx>
• Fw: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
  • From: NeilBrown <neilb@xxxxxxx>
• Re: linux-next: Tree for January 12 (dm-crypt)
  • From: Randy Dunlap <randy.dunlap@xxxxxxxxxx>
• Re: [PATCH]md:dm.c Fix warning: statement with no effect
  • From: Justin Mattock <justinmattock@xxxxxxxxx>
• Re: [PATCH]md:dm.c Fix warning: statement with no effect
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• [PATCH v4] dm mpath: delay retry of activate_path on SCSI_DH_RETRY
  • From: Mike Snitzer <snitzer@xxxxxxxxxx>
• Re: PROBLEM: SSD access time with dm-crypt is way too high
  • From: Yakov Hrebtov <hrebtov@xxxxxxxxx>
• Re: [PATCH] PROBLEM: SSD access time with dm-crypt is way too high
  • From: Michael Zugelder <michaelzugelder@xxxxxxxxxxxxxx>
• Re: [PATCH v3 0/8] dm-raid (raid456) target
  • From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
• Re: [PATCH] PROBLEM: SSD access time with dm-crypt is way too high
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [PATCH] PROBLEM: SSD access time with dm-crypt is way too high
  • From: Milan Broz <mbroz@xxxxxxxxxx>
• [PATCH] PROBLEM: SSD access time with dm-crypt is way too high
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: trim support (discard)
  • From: Jens Kasten <jens@xxxxxxxxxxxxx>