Linux Device-Mapper Development
[Prev Page][Next Page]
- [PATCH] [PATCH] option to multipath to not modify the bindinfs file
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: [BUG] multipath-tools: uuid has become meaningless
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- pvmove hangs
- From: "Allen, Jack" <Jack.Allen@xxxxxxxxxxxx>
- Re: [PATCH 5/5] dm: implement REQ_FLUSH/FUA support
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 2/5] virtio_blk: implement REQ_FLUSH/FUA support
- From: Christoph Hellwig <hch@xxxxxx>
- [PATCH 5/5] dm: implement REQ_FLUSH/FUA support
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 1/5] block/loop: implement REQ_FLUSH/FUA support
- From: Tejun Heo <tj@xxxxxxxxxx>
- [RFC PATCHSET block#for-2.6.36-post] block: convert to REQ_FLUSH/FUA
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 2/5] virtio_blk: implement REQ_FLUSH/FUA support
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 4/5] md: implment REQ_FLUSH/FUA support
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 3/5] lguest: replace VIRTIO_F_BARRIER support with VIRTIO_F_FLUSH/FUA support
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH UPDATED 10/11] fs, block: propagate REQ_FLUSH/FUA interface to upper layers
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [lvm-devel] linux-2.6.35+ causes LVM to fail with " device-mapper: version ioctl failed: Inappropriate ioctl for device"
- From: Jeff Chua <jeff.chua.linux@xxxxxxxxx>
- Re: [lvm-devel] linux-2.6.35+ causes LVM to fail with " device-mapper: version ioctl failed: Inappropriate ioctl for device"
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: [lvm-devel] linux-2.6.35+ causes LVM to fail with " device-mapper: version ioctl failed: Inappropriate ioctl for device"
- From: Jeff Chua <jeff.chua.linux@xxxxxxxxx>
- Re: [lvm-devel] linux-2.6.35+ causes LVM to fail with " device-mapper: version ioctl failed: Inappropriate ioctl for device"
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: linux-2.6.35+ causes LVM to fail with " device-mapper: version ioctl failed: Inappropriate ioctl for device"
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Re: linux-2.6.35+ causes LVM to fail with " device-mapper: version ioctl failed: Inappropriate ioctl for device"
- From: Jeff Chua <jeff.chua.linux@xxxxxxxxx>
- Re: linux-2.6.35+ causes LVM to fail with " device-mapper: version ioctl failed: Inappropriate ioctl for device"
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: linux-2.6.35+ causes LVM to fail with " device-mapper: version ioctl failed: Inappropriate ioctl for device"
- From: Jeff Chua <jeff.chua.linux@xxxxxxxxx>
- Re: linux-2.6.35+ causes LVM to fail with " device-mapper: version ioctl failed: Inappropriate ioctl for device"
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: linux-2.6.35+ causes LVM to fail with " device-mapper: version ioctl failed: Inappropriate ioctl for device"
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- linux-2.6.35+ causes LVM to fail with " device-mapper: version ioctl failed: Inappropriate ioctl for device"
- From: Jeff Chua <jeff.chua.linux@xxxxxxxxx>
- Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH 03/11] block: deprecate barrier and replace blk_queue_ordered() with blk_queue_flush()
- From: "hch@xxxxxx" <hch@xxxxxx>
- Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH 02/11] block: kill QUEUE_ORDERED_BY_TAG
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH 02/11] block: kill QUEUE_ORDERED_BY_TAG
- From: Vladislav Bolkhovitin <vst@xxxxxxxx>
- Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
- From: Vladislav Bolkhovitin <vst@xxxxxxxx>
- Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH} dm-throttle: new device mapper target to throttle reads and writes
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- Re: [PATCH 10/11] fs, block: propagate REQ_FLUSH/FUA interface to upper layers
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH 10/11] fs, block: propagate REQ_FLUSH/FUA interface to upper layers
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCH 10/11] fs, block: propagate REQ_FLUSH/FUA interface to upper layers
- From: Jan Kara <jack@xxxxxxx>
- Re: [PATCH] dm-throttle: new device mapper target to throttle reads and writes
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- Re: [PATCH} dm-throttle: new device mapper target to throttle reads and writes
- From: Vivek Goyal <vgoyal@xxxxxxxxxx>
- Re: [PATCH} dm-throttle: new device mapper target to throttle reads and writes
- From: Vivek Goyal <vgoyal@xxxxxxxxxx>
- Re: [PATCH] dm-throttle: new device mapper target to throttle reads and writes
- From: Vivek Goyal <vgoyal@xxxxxxxxxx>
- [PATCH 05/11] block: misc cleanups in barrier code
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 01/11] block/loop: queue ordered mode should be DRAIN_FLUSH
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 04/11] block: remove spurious uses of REQ_HARDBARRIER
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 02/11] block: kill QUEUE_ORDERED_BY_TAG
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 09/11] block: implement REQ_FLUSH/FUA based interface for FLUSH/FUA requests
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 07/11] block: rename blk-barrier.c to blk-flush.c
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 11/11] block: use REQ_FLUSH in blkdev_issue_flush()
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 06/11] block: drop barrier ordering by queue draining
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 10/11] fs, block: propagate REQ_FLUSH/FUA interface to upper layers
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 08/11] block: rename barrier/ordered to flush
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCH} dm-throttle: new device mapper target to throttle reads and writes
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- [git pull] device-mapper patches for 2.6.36
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- multipath-tools/multipath multipath.conf.5
- From: bmarzins@xxxxxxxxxxxxxx
- multipath-tools/libmultipath discovery.c
- From: bmarzins@xxxxxxxxxxxxxx
- Re: [REVISED PULL REQUEST] md updates for 2.6.36
- From: Neil Brown <neilb@xxxxxxx>
- Re: [PATCH] dm-throttle: new device mapper target to throttle reads and writes
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- Re: [REVISED PULL REQUEST] md updates for 2.6.36
- From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
- Re: [PATCH} dm-throttle: new device mapper target to throttle reads and writes
- From: Vivek Goyal <vgoyal@xxxxxxxxxx>
- Re: [PATCH} dm-throttle: new device mapper target to throttle reads and writes
- From: Vivek Goyal <vgoyal@xxxxxxxxxx>
- [PATCH} dm-throttle: new device mapper target to throttle reads and writes
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- Re: [Patch] scsi_dh_rdac: retry IO for 06/3f/03 in rdac_check_sense fn
- From: Chandra Seetharaman <sekharan@xxxxxxxxxx>
- [REVISED PULL REQUEST] md updates for 2.6.36
- From: Neil Brown <neilb@xxxxxxx>
- multipath-tools ./multipath.conf.defaults libm ...
- From: bmarzins@xxxxxxxxxxxxxx
- multipath-tools ./multipath.conf.defaults libm ...
- From: bmarzins@xxxxxxxxxxxxxx
- multipath-tools/multipathd main.c
- From: bmarzins@xxxxxxxxxxxxxx
- Re: [PATCH REPOST RFC] relaxed barriers
- From: Christoph Hellwig <hch@xxxxxx>
- [PULL REQUEST] md updates for 2.6.36
- From: Neil Brown <neilb@xxxxxxx>
- Re: [PATCH, RFC] relaxed barriers
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH, RFC] relaxed barriers
- From: Tejun Heo <tj@xxxxxxxxxx>
- Questions about dm-raid isw (device naming and partition table)
- From: tormen <tormen@xxxxxxx>
- How does dm-raid isw compare to other linux software raid solutions (e.g. mdadm)?
- From: tormen <tormen@xxxxxxx>
- Re: dm: Fixes memory leak in setup_indexes function
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH] dm: Fixes memory leak in setup_indexes function
- From: Shahzad Hussain Bangash <ext-shahzad.bangash@xxxxxxxxx>
- Re: [PATCH RESEND 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCH RESEND 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
- From: Jeff Moyer <jmoyer@xxxxxxxxxx>
- Re: direct-io regression [Was: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs]
- From: Chris Mason <chris.mason@xxxxxxxxxx>
- Re: [PATCH RESEND 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
- From: Vladislav Bolkhovitin <vst@xxxxxxxx>
- Re: direct-io regression [Was: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs]
- From: Jeff Moyer <jmoyer@xxxxxxxxxx>
- Re: [PATCH RESEND 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
- From: Jeff Moyer <jmoyer@xxxxxxxxxx>
- Re: direct-io regression [Was: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs]
- From: Chris Mason <chris.mason@xxxxxxxxxx>
- Re: [PATCH 2/2] dm-kcopyd: Delayed unplug of queues
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: [PATCH 1/2] dm-kcopyd: Remove BIO_RW_SYNCIO flag
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: direct-io regression [Was: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs]
- From: Josef Bacik <josef@xxxxxxxxxx>
- Re: direct-io regression [Was: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs]
- From: Chris Mason <chris.mason@xxxxxxxxxx>
- [PATCH] : Fix for memory leak in setup indexes
- From: Shahzad Hussain Bangash <ext-shahzad.bangash@xxxxxxxxx>
- Re: [PATCH, RFC 2/2] dm: support REQ_FLUSH directly
- From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
- Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
- From: Neil Brown <neilb@xxxxxxx>
- Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
- From: Valdis.Kletnieks@xxxxxx
- Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
- From: Mikael Abrahamsson <swmike@xxxxxxxxx>
- Re: How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs
- From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
- Re: [PATCH, RFC 2/2] dm: support REQ_FLUSH directly
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH, RFC 2/2] dm: support REQ_FLUSH directly
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
- Re: [PATCH, RFC 2/2] dm: support REQ_FLUSH directly
- From: Christoph Hellwig <hch@xxxxxx>
- [PATCH, RFC 1/2] relaxed cache flushes
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH] multipath: add fast_io_fail and dev_loss_tmo config parameters
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
- Re: [PATCH] coda: rename REQ_* to CODA_REQ_*
- From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
- [PATCH] coda: rename REQ_* to CODA_REQ_*
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCH 1/2 block#for-2.6.36] bio, fs: update RWA_MASK, READA and SWRITE to match the corresponding BIO_RW_* bits
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCH 1/2 block#for-2.6.36] bio, fs: update RWA_MASK, READA and SWRITE to match the corresponding BIO_RW_* bits
- From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
- Re: [PATCH 1/2 block#for-2.6.36] bio, fs: update RWA_MASK, READA and SWRITE to match the corresponding BIO_RW_* bits
- From: Jens Axboe <axboe@xxxxxxxxx>
- [PATCH 2/2 block#for-2.6.36] bio, fs: separate out bio_types.h and define READ/WRITE constants in terms of BIO_RW_* flags
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 1/2 block#for-2.6.36] bio, fs: update RWA_MASK, READA and SWRITE to match the corresponding BIO_RW_* bits
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCH RESEND 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCH 3/3] dm: separate device deletion from dm_put()
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
- Re: [RFC 1/2] block: implement an unprep function corresponding directly to prep
- From: Mark Lord <kernel@xxxxxxxxxxxx>
- Re: [PATCH] multipath: add fast_io_fail and dev_loss_tmo config parameters
- From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
- Re: [PATCH RESEND 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
- From: Neil Brown <neilb@xxxxxxx>
- Re: [PATCH RESEND 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
- From: Jens Axboe <axboe@xxxxxxxxx>
- [PATCH RESEND 2/2 block#for-linus] bio, fs: separate out bio_types.h and define READ/WRITE constants in terms of BIO_RW_* flags
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH RESEND 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH RESEND 2/2 block#for-linus] bio, fs: separate out bio_types.h and define READ/WRITE constants in terms of BIO_RW_* flags
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH RESEND 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 2/2 block#for-linus] bio, fs: separate out bio_types.h and define READ/WRITE constants in terms of BIO_RW_* flags
- From: Tejun Heo <tj@xxxxxxxxxx>
- [PATCH 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
- From: Tejun Heo <tj@xxxxxxxxxx>
- [Patch] scsi_dh_rdac: retry IO for 06/3f/03 in rdac_check_sense fn
- From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxx>
- Re: RAID/block regression starting from 2.6.32, bisected
- From: Neil Brown <neilb@xxxxxxx>
- Re: [PATCH] ext4: fix freeze deadlock under IO
- From: "Ted Ts'o" <tytso@xxxxxxx>
- Re: [PATCH]md:dm.c Fix warning: statement with no effect
- From: "Justin P. Mattock" <justinmattock@xxxxxxxxx>
- Re: [PATCH]md:dm.c Fix warning: statement with no effect
- From: "Justin P. Mattock" <justinmattock@xxxxxxxxx>
- Re: [PATCH]md:dm.c Fix warning: statement with no effect
- From: "Justin P. Mattock" <justinmattock@xxxxxxxxx>
- Re: [PATCH]md:dm.c Fix warning: statement with no effect
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: [PATCH 0/6] scsi_dh : Couple of fixes for scsi device handlers
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- Re: [PATCH 0/6] scsi_dh : Couple of fixes for scsi device handlers
- From: Shyam Iyer <shyam_iyer@xxxxxxxx>
- Re: [PATCH 0/6] scsi_dh : Couple of fixes for scsi device handlers
- From: Chandra Seetharaman <sekharan@xxxxxxxxxx>
- Re: [PATCH 2/6] scsi_dh : increment the refcounts while calling activate
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- Re: [PATCH 0/6] scsi_dh : Couple of fixes for scsi device handlers
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- Re: RAID/block regression starting from 2.6.32, bisected
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [PATCH] multipath: add fast_io_fail and dev_loss_tmo config parameters
- From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
- Re: [PATCH 3/6] scsi_dh : release the refcounts in scsi_dh_alua handler when activate is complete
- From: James Bottomley <James.Bottomley@xxxxxxx>
- Re: [PATCH 2/6] scsi_dh : increment the refcounts while calling activate
- From: James Bottomley <James.Bottomley@xxxxxxx>
- Re: [PATCH 0/6] scsi_dh : Couple of fixes for scsi device handlers
- From: Chandra Seetharaman <sekharan@xxxxxxxxxx>
- Re: [PATCH 0/6] scsi_dh : Couple of fixes for scsi device handlers
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- Re: [PATCH 0/6] scsi_dh : Couple of fixes for scsi device handlers
- From: Chandra Seetharaman <sekharan@xxxxxxxxxx>
- [PATCH] Add support for dm-mod module autoloading
- From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
- [PATCH 0/8] The DM part of dm-raid45
- From: NeilBrown <nfbrown@xxxxxxxxxx>
- [PATCH 5/8] dm-raid456: add suspend/resume method
- From: NeilBrown <nfbrown@xxxxxxxxxx>
- [PATCH 1/8] md/dm: create dm-raid456 module using md/raid5
- From: NeilBrown <nfbrown@xxxxxxxxxx>
- [PATCH 7/8] dm-dirty-log: allow log size to be different from target size.
- From: NeilBrown <nfbrown@xxxxxxxxxx>
- Re: [RFC 1/2] block: implement an unprep function corresponding directly to prep
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: [PATCH v2] scsi: address leak in scsi_setup_discard_cmnd error path (was: Re: scsi: unify the error handling of the prep functions)
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 2/8] dm-raid456: add congestion checking.
- From: NeilBrown <nfbrown@xxxxxxxxxx>
- [PATCH]md:dm.c Fix warning: statement with no effect
- From: "Justin P. Mattock" <justinmattock@xxxxxxxxx>
- Re: [RFC 1/2] block: implement an unprep function corresponding directly to prep
- From: Mark Lord <kernel@xxxxxxxxxxxx>
- Re: [RFC 1/2] block: implement an unprep function corresponding directly to prep
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: [RFC 1/2] block: implement an unprep function corresponding directly to prep
- From: Mark Lord <kernel@xxxxxxxxxxxx>
- Re: [PATCH v2] scsi: address leak in scsi_setup_discard_cmnd error path
- From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
- [PATCH] scsi: unify the error handling of the prep functions
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: disallow FS recursion from sb_issue_discard allocation
- From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
- [PATCH 8/8] dm-raid456: switch to use dm_dirty_log for tracking dirty regions.
- From: NeilBrown <nfbrown@xxxxxxxxxx>
- [PATCH 4/8] dm-raid456: add support for setting IO hints.
- From: NeilBrown <nfbrown@xxxxxxxxxx>
- [PATCH 3/8] dm-raid456: support unplug
- From: NeilBrown <nfbrown@xxxxxxxxxx>
- Re: [PATCH v2] scsi: address leak in scsi_setup_discard_cmnd error path
- From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
- [PATCH 6/8] dm-raid456: add message handler.
- From: NeilBrown <nfbrown@xxxxxxxxxx>
- Re: scsi: address leak in the error path of discard page allocation
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: [BUG] please PLEASE UnSubscribe!!!
- From: W S <whatisee1@xxxxxxxxx>
- RAID/block regression starting from 2.6.32, bisected
- From: Vladislav Bolkhovitin <vst@xxxxxxxx>
- Re: [PATCH 2/6] scsi_dh : increment the refcounts while calling activate
- From: Shyam Iyer <shyam_iyer@xxxxxxxx>
- Re: disallow FS recursion from sb_issue_discard allocation
- From: "Ted Ts'o" <tytso@xxxxxxx>
- [PATCH 1/6] scsi_dh : rename and export __detach_handler
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- [PATCH 5/6] scsi_dh : release the refcounts in scsi_dh_hp_sw handler when activate is complete
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- [PATCH 6/6] scsi_dh : release the refcounts in scsi_dh_rdac handler when activate is complete
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- [PATCH 0/6] scsi_dh : Couple of fixes for scsi device handlers
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- [PATCH 2/6] scsi_dh : increment the refcounts while calling activate
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- [PATCH] scsi_dh_rdac : Adding MODULE VERSION for rdac device handler
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- [PATCH 4/6] scsi_dh : release the refcounts in scsi_dh_emc handler when activate is complete
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- [PATCH 3/6] scsi_dh : release the refcounts in scsi_dh_alua handler when activate is complete
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- [PATCH 1/2 v2] dm stripe: move sector translation to a function
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: BIO_RW_SYNCIO
- From: Vivek Goyal <vgoyal@xxxxxxxxxx>
- [PATCH 1.5/2 v2] dm stripe: optimize sector division
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 1.5/2] dm-stripe: optimize sector division
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- [PATCH] dm: use dm_target_offset in targets
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 1.5/2] dm-stripe: optimize sector division
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [OT] How to associate pci id with wwpn for an hba
- From: Gianluca Cecchi <gianluca.cecchi@xxxxxxxxx>
- Re: BIO_RW_SYNCIO
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: BIO_RW_SYNCIO
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: [OT] How to associate pci id with wwpn for an hba
- From: Jonathan Barber <jonathan.barber@xxxxxxxxx>
- [OT] How to associate pci id with wwpn for an hba
- From: Gianluca Cecchi <gianluca.cecchi@xxxxxxxxx>
- Re: BIO_RW_SYNCIO
- From: Vivek Goyal <vgoyal@xxxxxxxxxx>
- [PATCH] [RFC] dm-multipath: typo, strncat instead of strncpy
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: [PATCH 2/2 v2] dm stripe: enable discard support
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 2/2 v2] dm stripe: enable discard support
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 1.5/2] dm-stripe: optimize sector division
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: BIO_RW_SYNCIO
- From: Vivek Goyal <vgoyal@xxxxxxxxxx>
- Re: [PATCH 2/2] dm-stripe: discard support
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 1.5/2] dm-stripe: optimize sector division
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- [PATCH 2/2] dm-stripe: discard support
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- [PATCH 1/2] dm-stripe: move sector translation to a function
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- [PATCH v3 12/12] dm stripe: enable efficient discard support
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: BIO_RW_SYNCIO
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: disallow FS recursion from sb_issue_discard allocation
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH v2 10/12] block: update request stacking methods to support discards
- From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
- Re: [PATCH] disallow FS recursion from sb_issue_discard allocation
- From: "Ted Ts'o" <tytso@xxxxxxx>
- Re: BIO_RW_SYNCIO
- From: Vivek Goyal <vgoyal@xxxxxxxxxx>
- BIO_RW_SYNCIO
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- [PATCH v3 06/12] dm: split discard requests on target boundaries
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v3 05/12] dm: factor max_io_len for code reuse
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v3 11/12] dm mpath: enable discard support
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: rq-based mpath failed path on SCSI target failure (malformed discard)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: rq-based mpath failed path on SCSI target failure (malformed discard)
- From: Mike Christie <michaelc@xxxxxxxxxxx>
- Re: rq-based mpath failed path on SCSI target failure (malformed discard)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- rq-based mpath failed path on SCSI target failure (malformed discard)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2 04/12] dm: use common __issue_target_request for flush and discard support
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2 03/12] dm: remove the DM_TARGET_SUPPORTS_DISCARDS feature flag
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2 02/12] dm: introduce num_discard_requests in dm_target structure
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2 06/12] dm: split discard requests on target boundaries
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2 07/12] dm zero: silently drop discards too
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2 05/12] dm: factor max_io_len for code reuse
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2 08/12] dm error: return error for discards too
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2 12/12] dm stripe: enable efficient discard support
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2 09/12] dm delay: enable discard support
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2 10/12] block: update request stacking methods to support discards
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2 00/12] dm: enable discard support for more targets
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2 01/12] dm: rename map_info flush_request to target_request_nr
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2 11/12] dm mpath: enable discard support
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 10/12] block: update request stacking methods to support discards
- From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
- [PATCH 10/12] block: update request stacking methods to support discards
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 07/12] dm zero: silently drop discards too
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 05/12] dm: factor max_io_len for code reuse
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 02/12] dm: introduce num_discard_requests in dm_target structure
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 09/12] dm delay: enable discard support
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 06/12] dm: split discard requests on target boundaries
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 01/12] dm: rename map_info flush_request to target_request_nr
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 00/12] dm: enable discard support for more targets
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 12/12] dm stripe: enable efficient discard support
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 03/12] dm: remove the DM_TARGET_SUPPORTS_DISCARDS feature flag
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 04/12] dm: use common __issue_target_request for flush and discard support
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 11/12] dm mpath: enable discard support
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 08/12] dm error: return error for discards too
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 3/3] dm: separate device deletion from dm_put()
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- [patch 2/2] multipath-tools: Intialize pointer passed to get_cmdvec
- From: Christof Schmitt <christof.schmitt@xxxxxxxxxx>
- [patch 0/2] multipath-tools fixes
- From: Christof Schmitt <christof.schmitt@xxxxxxxxxx>
- [patch 1/2] multipath-tools: Assign correct pointer from REALLOC
- From: Christof Schmitt <christof.schmitt@xxxxxxxxxx>
- [PATCH 2/2] dm-kcopyd: Delayed unplug of queues
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- [PATCH 1/2] dm-kcopyd: Remove BIO_RW_SYNCIO flag
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: [BUG] multipath-tools: uuid has become meaningless
- From: Hannes Reinecke <hare@xxxxxxx>
- Re: [BUG] multipath-tools: uuid has become meaningless
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- [PATCH] Fix typo in coalesce_paths
- From: hare@xxxxxxx (Hannes Reinecke)
- [PATCH] libmultipath: simplify dm_get_name()
- From: hare@xxxxxxx (Hannes Reinecke)
- [PATCH] libmultipath: always allocate space for alias
- From: hare@xxxxxxx (Hannes Reinecke)
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs v2
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- Re: [BUG] multipath-tools: uuid has become meaningless
- From: Hannes Reinecke <hare@xxxxxxx>
- Re: [BUG] multipath-tools: uuid has become meaningless
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: [BUG] multipath-tools: uuid has become meaningless
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- [BUG] multipath-tools: uuid has become meaningless
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs v2
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: [PATCH] [RFC] [PATCH] Add alias_prefix to get multipath names based on storage type
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- Re: [PATCH v4] dm: Add Dell MD36xxi controller into RDAC device list
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
- Re: [PATCH 1/1] dm-mpath: Extend path selectorinterface for supporting Dell EqualLogic path selector
- From: "Jason Shamberger" <Jason_Shamberger@xxxxxxxx>
- dmraid/lib/activate activate.h activate.c
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid Makefile.in
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/lib/format/ddf ddf1_dump.c
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/lib misc/misc.c locking/locking.c
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/lib/metadata reconfig.c
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/tools toollib.c
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/tools dmevent_tool.c
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/lib/format/ataraid asr.c
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/tools commands.c
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/lib/metadata metadata.c
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/lib/device scan.c
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid include/dmraid/dmraid.h include/dmraid/ ...
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid ./Makefile.in ./make.tmpl.in include/Ma ...
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/lib/format/ataraid lsi.c
- From: zkabelac@xxxxxxxxxxxxxx
- Re: [PATCH 1/1] dm-mpath: Extend path selector interface for supporting Dell EqualLogic path selector
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: [PATCH 1/1] dm-mpath: Extend path selector interface for supporting Dell EqualLogic path selector
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: dm barrier: A better test for -EOPNOTSUPP.
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH] dm barrier: A better test for -EOPNOTSUPP.
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: optimize one of the cache flushes
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH v2] scsi: address leak in scsi_setup_discard_cmnd error path (was: Re: scsi: unify the error handling of the prep functions)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: understanding of multipathing and speed
- From: Bart Coninckx <bart.coninckx@xxxxxxxxxx>
- Re: [PATCH 4/4] Support discard if at least one underlying device supports it
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: [PATCH] optimize one of the cache flushes
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: [PATCH 3/4] Support discard for multiple devices
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: [PATCH 2/4] Clear the discard flag if the device loses discard capability
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: [PATCH 1/4] Check that the target supports discard
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- [PATCH] optimize one of the cache flushes
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: understanding of multipathing and speed
- From: Brem Belguebli <brem.belguebli@xxxxxxxxx>
- Re: understanding of multipathing and speed
- From: Bart Coninckx <bart.coninckx@xxxxxxxxxx>
- any known problems when doing bio_clone() over an LVM snapshot?
- From: "Riches Jr, RobertX M" <robertx.m.riches.jr@xxxxxxxxx>
- Re: [PATCH v2] scsi: address leak in scsi_setup_discard_cmnd error path (was: Re: scsi: unify the error handling of the prep functions)
- From: Christoph Hellwig <hch@xxxxxx>
- Re: understanding of multipathing and speed
- From: Bart Coninckx <bart.coninckx@xxxxxxxxxx>
- Any way to access start/len of i/o from path selector?
- From: Brian Jackson <iggy@xxxxxxxxxxx>
- [PATCH] disallow FS recursion from sb_issue_discard allocation
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2] scsi: address leak in scsi_setup_discard_cmnd error path (was: Re: scsi: unify the error handling of the prep functions)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: Rescan for new LUNs
- From: brem belguebli <brem.belguebli@xxxxxxxxx>
- Re: Rescan for new LUNs
- From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
- Re: understanding of multipathing and speed
- From: bart.coninckx@xxxxxxxxxx
- Re: understanding of multipathing and speed
- From: bart.coninckx@xxxxxxxxxx
- Re: understanding of multipathing and speed
- From: brem belguebli <brem.belguebli@xxxxxxxxx>
- Re: understanding of multipathing and speed
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- Re: understanding of multipathing and speed
- From: bart.coninckx@xxxxxxxxxx
- Re: understanding of multipathing and speed
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- Re: understanding of multipathing and speed
- From: Bart Coninckx <bart.coninckx@xxxxxxxxxx>
- Re: understanding of multipathing and speed
- From: "John A. Sullivan III" <jsullivan@xxxxxxxxxxxxxxxxxxx>
- Re: [RFC 1/2] block: implement an unprep function corresponding directly to prep
- From: Jeff Garzik <jeff@xxxxxxxxxx>
- Re: [RFC 1/2] block: implement an unprep function corresponding directly to prep
- From: Christoph Hellwig <hch@xxxxxx>
- Re: understanding of multipathing and speed
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- understanding of multipathing and speed
- From: Bart Coninckx <bart.coninckx@xxxxxxxxxx>
- Re: scsi: unify the error handling of the prep functions
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 4/4] Support discard if at least one underlying device supports it
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: [PATCH 2/3] scsi: add sd_unprep_fn to free discard page
- From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
- Re: [PATCH 4/4] Support discard if at least one underlying device supports it
- From: Dmitry Monakhov <dmonakhov@xxxxxxxxxx>
- Re: [PATCH 4/4] Support discard if at least one underlying device supports it
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: [PATCH 4/4] Support discard if at least one underlying device supports it
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 4/4] Support discard if at least one underlying device supports it
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- GFP_KERNEL in ext4 (was: [PATCH 4/4] Support discard if at least one underlying device supports it)
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: [PATCH 4/4] Support discard if at least one underlying device supports it
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: [PATCH 4/4] Support discard if at least one underlying device supports it
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: [PATCH 4/4] Support discard if at least one underlying device supports it
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 1/4] Check that the target supports discard
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 2/4] Clear the discard flag if the device loses discard capability
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 3/4] Support discard for multiple devices
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 4/4] Support discard if at least one underlying device supports it
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- [PATCH 3/4] Support discard for multiple devices
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- [PATCH 2/4] Clear the discard flag if the device loses discard capability
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- [PATCH 1/4] Check that the target supports discard
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- [PATCH 0/4] discard updates
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: Is there a way to see updated contents of a DM target's underlying device while the DM target is in use?
- From: Hannes Reinecke <hare@xxxxxxx>
- Re: scsi: address leak in the error path of discard page allocation
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [RFC 1/2] block: implement an unprep function corresponding directly to prep
- From: Christoph Hellwig <hch@xxxxxx>
- Re: scsi: address leak in the error path of discard page allocation
- From: Christoph Hellwig <hch@xxxxxx>
- Re: scsi: address leak in the error path of discard page allocation
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH 3/3] scsi: remove unused free discard page in sd_done
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH] scsi: address leak in the error path of discard page allocation
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH 2/3] scsi: add sd_unprep_fn to free discard page
- From: Christoph Hellwig <hch@xxxxxx>
- Re: scsi: address leak in the error path of discard page allocation
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: scsi: address leak in the error path of discard page allocation
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: scsi: address leak in the error path of discard page allocation
- From: James Bottomley <James.Bottomley@xxxxxxx>
- Re: scsi: address leak in the error path of discard page allocation
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: Is there a way to see updated contents of a DM target's underlying device while the DM target is in use?
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: Rescan for new LUNs
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: Rescan for new LUNs
- From: "Allen, Jack" <Jack.Allen@xxxxxxxxxxxx>
- Re: Rescan for new LUNs
- From: "Allen, Jack" <Jack.Allen@xxxxxxxxxxxx>
- Re: Is there a way to see updated contents of a DM target's underlying device while the DM target is in use?
- From: "Riches Jr, RobertX M" <robertx.m.riches.jr@xxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: add sd_unprep_fn to free discard page
- From: James Bottomley <James.Bottomley@xxxxxxx>
- Re: add sd_unprep_fn to free discard page
- From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
- Re: [PATCH 1/3] block: implement an unprep function corresponding directly to prep
- From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
- [PATCH] scsi: address leak in the error path of discard page allocation
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: (no subject)
- From: Jens Axboe <axboe@xxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: Avoiding lvm shell crashes on white space only line
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- [PATCH 3/3] scsi: remove unused free discard page in sd_done
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- (no subject)
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 2/3] scsi: add sd_unprep_fn to free discard page
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 1/3] block: implement an unprep function corresponding directly to prep
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: [PATCH 1/1] dm-mpath: Extend path selector interface for supporting Dell EqualLogic path selector
- From: Hannes Reinecke <hare@xxxxxxx>
- Re: Rescan for new LUNs
- From: Oren Held <oren@xxxxxxxxxxx>
- Avoiding lvm shell crashes on white space only line
- From: Xinwei Hu <hxinwei@xxxxxxxxx>
- Re: [RFC 1/2] block: implement an unprep function corresponding directly to prep
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: [RFC 1/2] block: implement an unprep function corresponding directly to prep
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: Is there a way to see updated contents of a DM target's underlying device while the DM target is in use?
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: [RFC 1/2] block: implement an unprep function corresponding directly to prep
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: Rescan for new LUNs
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: Is there a way to see updated contents of a DM target's underlying device while the DM target is in use?
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Rescan for new LUNs
- From: "Allen, Jack" <Jack.Allen@xxxxxxxxxxxx>
- Re: Is there a way to see updated contents of a DM target's underlying device while the DM target is in use?
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: Is there a way to see updated contents of a DM target's underlying device while the DM target is in use?
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: Is there a way to see updated contents of a DM target's underlying device while the DM target is in use?
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: Is there a way to see updated contents of a DM target's underlying device while the DM target is in use?
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: Is there a way to see updated contents of a DM target's underlying device while the DM target is in use?
- From: Neil Brown <neilb@xxxxxxx>
- Re: Is there a way to see updated contents of a DM target's underlying device while the DM target is in use?
- From: "Riches Jr, RobertX M" <robertx.m.riches.jr@xxxxxxxxx>
- Re: Is there a way to see updated contents of a DM target's underlying device while the DM target is in use?
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Is there a way to see updated contents of a DM target's underlying device while the DM target is in use?
- From: "Riches Jr, RobertX M" <robertx.m.riches.jr@xxxxxxxxx>
- Re: [RFC 1/2] block: implement an unprep function corresponding directly to prep
- From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
- Re: [RFC 1/2] block: implement an unprep function corresponding directly to prep
- From: Jens Axboe <axboe@xxxxxxxxx>
- Re: [RFC 1/2] block: implement an unprep function corresponding directly to prep
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [RFC 2/2] sd: free discard page in unprep function
- From: James Bottomley <James.Bottomley@xxxxxxx>
- [RFC 1/2] block: implement an unprep function corresponding directly to prep
- From: James Bottomley <James.Bottomley@xxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: James Bottomley <James.Bottomley@xxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: James Bottomley <James.Bottomley@xxxxxxx>
- Re: [PATCH 1/1] dm-mpath: Extend path selector interface for supporting Dell EqualLogic path selector
- From: "Jason Shamberger" <Jason_Shamberger@xxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: James Bottomley <James.Bottomley@xxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: [PATCH 1/1] dm-mpath: Extend path selector interface for supporting Dell EqualLogic path selector
- From: "Narendran Ganapathy" <Narendran_Ganapathy@xxxxxxxx>
- [PATCH v5 2/2 "v12"] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v5 1/2] dm: prevent table type changes after initial table load
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH v4 1/2] dm: prevent table type changes after initial table load
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH v4 1/2] dm: prevent table type changes after initial table load
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: [PATCH v4 1/2] dm: prevent table type changes after initial table load
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH v4 1/2] dm: prevent table type changes after initial table load
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: [PATCH 1/1] dm-mpath: Extend path selector interface for supporting Dell EqualLogic path selector
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
- Re: [PATCH 1/1] dm-mpath: Extend path selector interface for supporting Dell EqualLogic path selector
- From: Hannes Reinecke <hare@xxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Boaz Harrosh <bharrosh@xxxxxxxxxxx>
- Re: [PATCH] [RFC] [PATCH] Add alias_prefix to get multipath names based on storage type
- From: Hannes Reinecke <hare@xxxxxxx>
- Re: [PATCH] [RFC] [PATCH] Add alias_prefix to get multipath names based on storage type
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- Re: [PATCH 1/2 v3] dm: discard support for the linear target
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 1/2 v3] dm: discard support for the linear target
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Problem using dm-ioband
- From: Jia Rao <rickenrao@xxxxxxxxx>
- Re: [PATCH] [RFC] [PATCH] Add alias_prefix to get multipath names based on storage type
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
- Re: [PATCH 1/2 v2] dm: discard support for the linear target
- From: Edward Thornber <thornber@xxxxxxxxxx>
- Re: [PATCH 2/2] block: defer the use of inline biovecs for discard requests
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH 2/2] block: defer the use of inline biovecs for discard requests
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [PATCH 1/1] dm-mpath: Extend path selector interface for supporting Dell EqualLogic path selector
- From: "Narendran Ganapathy" <Narendran_Ganapathy@xxxxxxxx>
- Re: [PATCH 2/2] block: defer the use of inline biovecs for discard requests
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH 2/2] block: defer the use of inline biovecs for discard requests
- From: Jens Axboe <axboe@xxxxxxxxx>
- Re: [PATCH 2/2] block: defer the use of inline biovecs for discard requests
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 2/2] block: defer the use of inline biovecs for discard requests
- From: Jens Axboe <axboe@xxxxxxxxx>
- Re: [PATCH 2/2] block: defer the use of inline biovecs for discard requests
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 2/2] block: defer the use of inline biovecs for discard requests
- From: Jens Axboe <axboe@xxxxxxxxx>
- Re: [PATCH 2/2] block: defer the use of inline biovecs for discard requests
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 2/2] block: defer the use of inline biovecs for discard requests
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Jens Axboe <axboe@xxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Christoph Hellwig <hch@xxxxxx>
- [ANNOUNCE] dds snapshot based remote async replication
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH 2/2 v2] block: defer the use of inline biovecs for discard requests
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: James Bottomley <James.Bottomley@xxxxxxx>
- [PATCH 2/2 v2] block: defer the use of inline biovecs for discard requests
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 2/2] block: defer the use of inline biovecs for discard requests
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [RFC PATCH 2/2] dm: add support for splitting discard requests
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 1/2 v2] dm: discard support for the linear target
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- Re: [PATCH 1/2 v2] dm: discard support for the linear target
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [RFC PATCH 2/2] dm: add support for splitting discard requests
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH 2/2] block: defer the use of inline biovecs for discard requests
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Christoph Hellwig <hch@xxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Christoph Hellwig <hch@xxxxxx>
- Re: multipathd daemon and some bad behavior
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- Re: [PATCH 1/2] block: fix leaks associated with discard request payload
- From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
- [RFC PATCH 2/2] dm: add support for splitting discard requests
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 1/2 v2] dm: discard support for the linear target
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 1/2] block: fix leaks associated with discard request payload
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 2/2] block: defer the use of inline biovecs for discard requests
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH] ext4: fix freeze deadlock under IO
- From: Eric Sandeen <sandeen@xxxxxxxxxxx>
- multipath-tools libmultipath/configure.c libmu ...
- From: bmarzins@xxxxxxxxxxxxxx
- Re: Make device-mapper udev rules more friendly to udev
- From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
- Make device-mapper udev rules more friendly to udev
- From: Xinwei Hu <hxinwei@xxxxxxxxx>
- Fix typo in libdm/ioctl/libdm-iface.c
- From: Xinwei Hu <hxinwei@xxxxxxxxx>
- [PATCH] [RFC] [PATCH] Add alias_prefix to get multipath names based on storage type
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: [PATCH, RFC] block: don't allocate a payload for discard request
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 00/24] dm-raid456 support using md/raid5.c, now with dirty-log
- From: Neil Brown <neilb@xxxxxxx>
- Re: [PATCH, RFC] block: don't allocate a payload for discard request
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: multipath-tools only binding 2 out of 4 paths, bug w/ numerous devices?
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- Re: 2.6.35 causes deadlock when snapshotting root lv
- From: Eric Sandeen <sandeen@xxxxxxxxxxx>
- Re: 2.6.35 causes deadlock when snapshotting root lv
- From: Eric Sandeen <sandeen@xxxxxxxxxxx>
- Re: multipath-tools only binding 2 out of 4 paths, bug w/ numerous devices?
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
- Re: 2.6.35 causes deadlock when snapshotting root lv
- From: Eric Sandeen <sandeen@xxxxxxxxxxx>
- Re: [PATCH 00/24] dm-raid456 support using md/raid5.c, now with dirty-log
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- Re: [PATCH 00/24] dm-raid456 support using md/raid5.c, now with dirty-log
- From: Neil Brown <neilb@xxxxxxx>
- Re: 2.6.35 causes deadlock when snapshotting root lv
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Re: 2.6.35 causes deadlock when snapshotting root lv
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: 2.6.35 causes deadlock when snapshotting root lv
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Re: 2.6.35 causes deadlock when snapshotting root lv
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- 2.6.35 causes deadlock when snapshotting root lv
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Re: [PATCH 00/24] dm-raid456 support using md/raid5.c, now with dirty-log
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- Re: [PATCH 00/24] dm-raid456 support using md/raid5.c, now with dirty-log
- From: Neil Brown <neilb@xxxxxxx>
- [PATCH] dm: discard support for the linear target
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: 2 TB wraparound on snapshots on kernels < 2.6.33
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Re: 2 TB wraparound on snapshots on kernels < 2.6.33
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: 2 TB wraparound on snapshots on kernels < 2.6.33
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: [PATCH 00/24] dm-raid456 support using md/raid5.c, now with dirty-log
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- Re: [PATCH 00/24] dm-raid456 support using md/raid5.c, now with dirty-log
- From: Neil Brown <neilb@xxxxxxx>
- Re: 2 TB wraparound on snapshots on kernels < 2.6.33
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Re: [PATCH 00/24] dm-raid456 support using md/raid5.c, now with dirty-log
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- Re: 2 TB wraparound on snapshots
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Re: 2 TB wraparound on snapshots
- From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
- Re: 2 TB wraparound on snapshots
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Re: 2 TB wraparound on 32 bit host
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Re: 2 TB wraparound on 32 bit host
- From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
- Re: 2 TB wraparound on 32 bit host
- From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
- Re: 2 TB wraparound on 32 bit host
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Re: [PATCH] Fix kernel NULL pointer dereference in dm-mpath.c
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: 2 TB wraparound on 32 bit host
- From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
- 2 TB wraparound on 32 bit host
- From: Phillip Susi <psusi@xxxxxxxxxx>
- [PATCH] Fix kernel NULL pointer dereference in dm-mpath.c
- From: "Patrick J. LoPresti" <lopresti@xxxxxxxxx>
- Re: [PATCH 3/2] dm: table load must always try dm_setup_md_queue
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
- Re: discard/trim support in device mapper?
- From: Andreas Beckmann <beckmann@xxxxxxxxxxxxxxxxxxx>
- Re: [PATCH 3/2] dm: table load must always try dm_setup_md_queue
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 3/2] dm: table load must always try dm_setup_md_queue
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
- patches archive for replicator
- From: vivacious absolutely <vivacious@xxxxxxxx>
- [PATCH 3/3] dm: separate device deletion from dm_put()
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
- [PATCH 2/3] dm: release _hash_lock when removing device in remove_all
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
- [PATCH 1/3] dm: prevent access to md being deleted
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
- [PATCH 0/3] dm: separate device deletion from dm_put()
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
- [PATCH v4 3/3] init: add support to directly boot to a mapped device
- From: Will Drewry <wad@xxxxxxxxxxxx>
- [PATCH v4 1/3] dm: ensure dm_table_complete() completes a table for use
- From: Will Drewry <wad@xxxxxxxxxxxx>
- [PATCH v4 2/3] dm: export a table+mapped device to the ioctl interface
- From: Will Drewry <wad@xxxxxxxxxxxx>
- LinuxTag, Berlin, Weds 9 - Sat 12 June 2010
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- [PATCH 3/2] dm: table load must always try dm_setup_md_queue
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- dm-multipath + libcheckers/tur.c instability
- From: "William R. Lorenz" <wrl@xxxxxxxxxxx>
- [PATCH v4] block: avoid unconditionally freeing previously allocated request_queue
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v3] block: avoid unconditionally freeing previously allocated request_queue
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 21/24] dm-dirty-log: allow log size to be different from target size.
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- Re: [PATCH 21/24] dm-dirty-log: allow log size to be different from target size.
- From: Neil Brown <neilb@xxxxxxx>
- Re: [PATCH 21/24] dm-dirty-log: allow log size to be different from target size.
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
- Snapshots on block devices
- From: CoolCold <coolthecold@xxxxxxxxx>
- dmraid ./configure ./configure.in include/conf ...
- From: zkabelac@xxxxxxxxxxxxxx
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Andi Kleen <ak@xxxxxxxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: huang ying <huang.ying.caritas@xxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Andi Kleen <ak@xxxxxxxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Andi Kleen <ak@xxxxxxxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Steffen Klassert <steffen.klassert@xxxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Eric Dumazet <eric.dumazet@xxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Eric Dumazet <eric.dumazet@xxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- [PATCH 03/24] md/raid5: ensure we create a unique name for kmem_cache when mddev has no gendisk
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 08/24] dm-raid456: add support for raising events to userspace.
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 21/24] dm-dirty-log: allow log size to be different from target size.
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 12/24] md/plug: optionally use plugger to unplug an array during resync/recovery.
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 02/24] md/raid5: factor out code for changing size of stripe cache.
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 23/24] md/bitmap: separate out loading a bitmap from initialising the structures.
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 15/24] dm-raid456: add suspend/resume method
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 00/24] dm-raid456 support using md/raid5.c, now with dirty-log
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 19/24] md/bitmap: clean up plugging calls.
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 16/24] dm-raid456: add message handler.
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 10/24] dm-raid456: add congestion checking.
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 04/24] md: be more careful setting MD_CHANGE_CLEAN
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 06/24] md: export various start/stop interfaces
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 11/24] md/raid5: add simple plugging infrastructure.
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 20/24] md/bitmap: optimise scanning of empty bitmaps.
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 24/24] dm-raid456: switch to use dm_dirty_log for tracking dirty regions.
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 22/24] md/bitmap: prepare for storing write-intent-bitmap via dm-dirty-log.
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 14/24] dm-raid456: add support for setting IO hints.
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 17/24] md/bitmap: white space clean up and similar.
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 18/24] md/bitmap: reduce dependence on sysfs.
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 07/24] md/dm: create dm-raid456 module using md/raid5
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 13/24] dm-raid456: support unplug
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 09/24] raid5: Don't set read-ahead when there is no queue
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 05/24] md: split out md_rdev_init
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH 01/24] md: reduce dependence on sysfs.
- From: NeilBrown <neilb@xxxxxxx>
- [PATCH] DM-CRYPT: Scale to multiple CPUs v2
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Milan Broz <mbroz@xxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- Re: [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Milan Broz <mbroz@xxxxxxxxxx>
- [PATCH] DM-CRYPT: Scale to multiple CPUs
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- dmraid ./configure ./configure.in ./make.tmpl. ...
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid tools/Makefile.in include/config.h.in
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid configure.in configure
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/lib Makefile.in
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid make.tmpl.in
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/tools commands.c
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid ./configure ./configure.in ./make.tmpl. ...
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/tools version.h.in
- From: zkabelac@xxxxxxxxxxxxxx
- [ANNOUNCE] cryptsetup 1.1.2
- From: Milan Broz <mbroz@xxxxxxxxxx>
- dmraid/lib version.h
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid ./configure ./configure.in ./make.tmpl. ...
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/lib Makefile.in
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/tools Makefile.in
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid Makefile.in
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/man Makefile.in
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid lib/Makefile.in ./make.tmpl.in
- From: zkabelac@xxxxxxxxxxxxxx
- Re: General and configuration questions
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- Re: General and configuration questions
- From: "Allen, Jack" <Jack.Allen@xxxxxxxxxxxx>
- Re: General and configuration questions
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- General and configuration questions
- From: "Allen, Jack" <Jack.Allen@xxxxxxxxxxxx>
- dmraid/lib Makefile.in
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/tools relpath.awk
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid make.tmpl.in
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid configure configure.in
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid ./make.tmpl.in lib/Makefile.in lib/vers ...
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/lib Makefile.in
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/include Makefile.in
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/man Makefile.in
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/tools Makefile.in
- From: zkabelac@xxxxxxxxxxxxxx
- multipath-tools/libmultipath discovery.c structs.h
- From: bmarzins@xxxxxxxxxxxxxx
- dmraid configure configure.in make.tmpl.in
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/tools dmevent_tool.c
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/lib .export.sym
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/tools Makefile.in
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/lib Makefile.in
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid/include Makefile.in
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid configure configure.in make.tmpl.in
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid ./configure ./configure.in lib/Makefile ...
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid make.tmpl.in
- From: zkabelac@xxxxxxxxxxxxxx
- dmraid make.tmpl.in
- From: zkabelac@xxxxxxxxxxxxxx
- Re: [PATCH v3 2/3] init: boot to device-mapper targets without an initr*
- From: Will Drewry <wad@xxxxxxxxxxxx>
- [PATCH v4 2/2 "v11"] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v4 1/2] dm: prevent table type changes after initial table load
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v4 0/2] dm: restrict conflicting table loads and improve queue initialization
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH v3 2/3] init: boot to device-mapper targets without an initr*
- From: Anselm Busse <abusse@xxxxxxxxxxxxxxx>
- Re: [PATCH v3 1/2] dm: prevent table type changes after initial table load
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH v3 2/2 "v10"] dm: only initialize full request_queue for request-based device
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
- Re: [PATCH v3 1/2] dm: prevent table type changes after initial table load
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
- Re: how to load dm-multisnapshot [with LVM patch]
- From: Busby <chaimvy@xxxxxxxxx>
- Re: General questions
- From: Malahal Naineni <malahal@xxxxxxxxxx>
- General questions
- From: "Allen, Jack" <Jack.Allen@xxxxxxxxxxxx>
- Issue of RDAC array failback
- From: <Yanqing_Liu@xxxxxxxx>
- Re: how to load dm-multisnapshot [with LVM patch]
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Re: how to load dm-multisnapshot [with LVM patch]
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2] block: avoid unconditionally freeing previously allocated request_queue
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: block: avoid unconditionally freeing previously allocated request_queue
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: how to load dm-multisnapshot [with LVM patch]
- From: Busby <chaimvy@xxxxxxxxx>
- Re: [PATCH] block: avoid unconditionally freeing previously allocated request_queue
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
- multipath-tools/libmultipath discovery.c
- From: bmarzins@xxxxxxxxxxxxxx
- multipath-tools/multipath kpartx_get_name mpat ...
- From: bmarzins@xxxxxxxxxxxxxx
- [PATCH 2/1] block: make blk_init_free_list and elevator_init idempotent
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH] block: avoid unconditionally freeing previously allocated request_queue
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH v3 3/3] dm: lookup devices by path with name_to_dev_t
- From: Will Drewry <wad@xxxxxxxxxxxx>
- [PATCH v3 2/2 "v10"] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v3 0/2] dm: restrict conflicting table loads and improve queue initialization
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v3 1/2] dm: prevent table type changes after initial table load
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH] multipath: generic timeout function in dm-mpath
- From: Tomohiro Kusumi <kusumi.tomohiro@xxxxxxxxxxxxxx>
- Re: [PATCH v2 2/2 "v9"] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH v2 1/2] dm: prevent table type changes after initial table load
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH v2 2/2 "v9"] dm: only initialize full request_queue for request-based device
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
- Re: [PATCH v2 1/2] dm: prevent table type changes after initial table load
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
- Re: add devname module aliases to allow module on-demand auto-loading
- From: Kay Sievers <kay.sievers@xxxxxxxx>
- Re: add devname module aliases to allow module on-demand auto-loading
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: [ANNOUNCE] multipath-tools 0.4.9
- From: Christof Schmitt <christof.schmitt@xxxxxxxxxx>
- Re: add devname module aliases to allow module on-demand auto-loading
- From: Luca Berra <bluca@xxxxxxxxxx>
- Re: [PATCH v3 3/3] dm: lookup devices by path with name_to_dev_t
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2 1/2] dm: prevent table type changes after initial table load
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2 2/2 "v9"] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH v2 0/2] dm: restrict conflicting table loads and improve queue initialization
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH v3 3/3] dm: lookup devices by path with name_to_dev_t
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 0/6] dm: restrict conflicting table loads and improve queue initialization
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- Re: [PATCH 2/6] dm ioctl: interlock resume and table clear
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
- [PATCH 2/2] dm: export a table+mapped device to the ioctl interface
- From: Will Drewry <wad@xxxxxxxxxxxx>
- [PATCH 1/2] dm: ensure dm_table_complete() completes a table for use
- From: Will Drewry <wad@xxxxxxxxxxxx>
- Re: [PATCH v3 3/3] dm: lookup devices by path with name_to_dev_t
- From: Will Drewry <wad@xxxxxxxxxxxx>
- Re: [PATCH] multipath: add "count paths" multipathd command
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
- Re: Unable to build MPT 0.4.9
- From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
- Re: [PATCH v3 3/3] dm: lookup devices by path with name_to_dev_t
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: [PATCH v3 3/3] dm: lookup devices by path with name_to_dev_t
- From: Will Drewry <wad@xxxxxxxxxxxx>
- Re: Unable to build MPT 0.4.9
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
- Unable to build MPT 0.4.9
- From: "--[ UxBoD ]--" <uxbod@xxxxxxxxxxxx>
- Re: [PATCH v3 3/3] dm: lookup devices by path with name_to_dev_t
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: [PATCH v3 3/3] dm: lookup devices by path with name_to_dev_t
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
- Re: [PATCH 0/6] dm: restrict conflicting table loads and improve queue initialization
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
- Re: [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
- how to load dm-multisnapshot [with LVM patch]
- From: Busby <chaimvy@xxxxxxxxx>
- Re: [PATCH 1/6] block: Adjust elv_iosched_show to return "none" for bio-based DM
- From: Jens Axboe <jens.axboe@xxxxxxxxxx>
- Re: missing /sys/block/dm-*/queue
- From: Rodrigo Nascimento <nascimento.rp@xxxxxxxxx>
- lvm + dmmapper on a 2.6.32.10 kernel
- From: Bram Gillemon <bram@xxxxxxxxxx>
[Index of Archives]
[DM Crypt]
[Fedora Desktop]
[ATA RAID]
[Fedora Marketing]
[Fedora Packaging]
[Fedora SELinux]
[Yosemite Discussion]
[KDE Users]
[Fedora Docs]