Linux Device-Mapper Development

Thread Index

[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>
missing /sys/block/dm-*/queue
- From: Paul Raines <raines@xxxxxxxxxxxxxxxxxxx>
[PATCH] fix hard-coded disk header chunk size for persistent snapshot
- From: Tomohiro Kusumi <kusumi.tomohiro@xxxxxxxxxxxxxx>
Re: [PATCH] fix hard-coded disk header chunk size for persistent snapshot
- From: Tomohiro Kusumi <kusumi.tomohiro@xxxxxxxxxxxxxx>
Re: dm-devel Digest, Vol 75, Issue 12
- From: Dmitry Kushak <Dmitry.Kushak@xxxxxxxxxx>
Re: [PATCH] multipath: add "count paths" multipathd command
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
[patch] md/dm-log: use PTR_ERR value instead of -ENOMEM
- From: Dan Carpenter <error27@xxxxxxxxx>
[PATCH 3/6] dm: prevent table type changes after initial table load
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH 4/6 "v8"] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH 2/6] dm ioctl: interlock resume and table clear
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH 6/6] dm ioctl: introduce find_device_noinit
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH 5/6] dm ioctl: introduce dm_get_verified_mdptr
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH 1/6] block: Adjust elv_iosched_show to return "none" for bio-based DM
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH 0/6] dm: restrict conflicting table loads and improve queue initialization
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH RFC] device-mapper: verity, an integrity checking target
- From: wad@xxxxxxxxxxxx
Re: Questions regarding request based dm-multipath and blk-layer/elevator
- From: pg_devm@xxxxxxxxxxxxxxxxxxx (Peter Grandi)
[ANNOUNCE] cryptsetup 1.1.1
- From: Milan Broz <mbroz@xxxxxxxxxx>
[ANNOUNCE] multipath-tools 0.4.9
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
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: 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: [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH] dm: also check for conflicting table type in dm_table_set_type
- 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>
Re: Shared snapshot tests
- From: Busby <chaimvy@xxxxxxxxx>
[PATCH v7] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH] dm: also check for conflicting table type in dm_table_set_type
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
Re: Questions regarding request based dm-multipath and blk-layer/elevator
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
Re: Questions regarding request based dm-multipath and blk-layer/elevator
- From: Nikanth Karthikesan <knikanth@xxxxxxx>
[PATCH] multipath: don't clear daemon setting on reconfigure
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
[PATCH] multipath: close sysfs file after setting value
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
[PATCH] multipath: fix fast_io_fail_tmo typo
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
Re: [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH v6] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH 1/1] multipath_tools: Fixup IBM Virtual SCSI hwtable entries
- From: Brian King <brking@xxxxxxxxxxxxxxxxxx>
[PATCH v3 1/3] dm: allow a dm-fs-style device to be shared via dm-ioctl
- From: Will Drewry <wad@xxxxxxxxxxxx>
[PATCH v3 3/3] dm: lookup devices by path with name_to_dev_t
- From: Will Drewry <wad@xxxxxxxxxxxx>
[PATCH v3 2/3] init: boot to device-mapper targets without an initr*
- From: Will Drewry <wad@xxxxxxxxxxxx>
Re: Questions regarding request based dm-multipath and blk-layer/elevator
- From: Vivek Goyal <vgoyal@xxxxxxxxxx>
[PATCH v4] dm: Add Dell MD36xxi controller into RDAC device list
- From: <Yanqing_Liu@xxxxxxxx>
Re: [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Questions regarding request based dm-multipath and blk-layer/elevator
- From: Nikanth Karthikesan <knikanth@xxxxxxx>
Re: [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
[PATCH v5] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH] dm-ioctl: Remove useless __dev_status call for "device geometry" and "target message" ioctl
- From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
Re: [PATCH] dm-ioctl: Return data to userspace after rename ioctl is processed
- From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
Re: [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH] multipath: add udev sync support.
- From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
Re: [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
Re: [RFC PATCH v2 1/2] dm: allow a dm-fs-style device to be shared via dm-ioctl
- From: Will Drewry <wad@xxxxxxxxxxxx>
Re: [RFC PATCH v2 1/2] dm: allow a dm-fs-style device to be shared via dm-ioctl
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
Re: [PATCH] multipath: update redhat multipathd init script
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
[PATCH] multipath: add "count paths" multipathd command
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
[PATCH] multipath: add udev sync support.
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
[PATCH] multipath: update redhat multipathd init script
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
[PATCH v4] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [RFC PATCH v2 2/2] init: boot to device-mapper targets without an initr*
- From: Randy Dunlap <randy.dunlap@xxxxxxxxxx>
Re: [RFC PATCH v2 2/2] init: boot to device-mapper targets without an initr*
- From: Will Drewry <wad@xxxxxxxxxxxx>
Re: [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [RFC PATCH v2 2/2] init: boot to device-mapper targets without an initr*
- From: Randy Dunlap <randy.dunlap@xxxxxxxxxx>
Re: [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
[RFC PATCH v2 2/2] init: boot to device-mapper targets without an initr*
- From: Will Drewry <wad@xxxxxxxxxxxx>
[RFC PATCH v2 1/2] dm: allow a dm-fs-style device to be shared via dm-ioctl
- From: Will Drewry <wad@xxxxxxxxxxxx>
[PATCH 9/10] drivers/md: Use kstrdup
- From: Julia Lawall <julia@xxxxxxx>
[PATCH v3] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [RFC PATCH] dm: allow a dm-fs-style device to be shared via dm-ioctl
- From: Will Drewry <wad@xxxxxxxxxxxx>
Re: [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
Re: [RFC PATCH] dm: allow a dm-fs-style device to be shared via dm-ioctl
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[RFC PATCH] dm: allow a dm-fs-style device to be shared via dm-ioctl
- From: Will Drewry <wad@xxxxxxxxxxxx>
[PATCH 3/2 v2] dm: bio-based device must not register elevator in sysfs
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[RFC PATCH 3/2] dm: bio-based device must not register elevator in sysfs
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH 2/2 v2] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [RFC PATCH] init: boot to device-mapper targets without an initr*
- From: Will Drewry <wad@xxxxxxxxxxxx>
Re: [RFC PATCH] init: boot to device-mapper targets without an initr*
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
[RFC PATCH] init: boot to device-mapper targets without an initr*
- From: Will Drewry <wad@xxxxxxxxxxxx>
Re: [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
block_abort_queue (blk_abort_request) racing with scsi_request_fn
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
Re: [PATCH] fix hard-coded disk header chunk size for persistent snapshot
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
Re: [PATCH] fix hard-coded disk header chunk size for persistent snapshot
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
DM-MP Read Performance
- From: Rodrigo Nascimento <nascimento.rp@xxxxxxxxx>
Re: [PATCH-v2 2/2] Initialize mempool and elevator only for request-based dm devices
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [RFC PATCH 1/2] block: allow initialization of previously allocated request_queue
- From: Jens Axboe <jens.axboe@xxxxxxxxxx>
Re: [RFC PATCH 1/2] block: allow initialization of previously allocated request_queue
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [RFC PATCH 1/2] block: allow initialization of previously allocated request_queue
- From: Jens Axboe <jens.axboe@xxxxxxxxxx>
Re: [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
- From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx>
[RFC PATCH 1/2] block: allow initialization of previously allocated request_queue
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: Shared snapshot tests
- From: Daire Byrne <daire.byrne@xxxxxxxxx>
Testers needed - Maxtor performance degradation
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
[PATCH] device-mapper cluster locking
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
Re: [PATCH 0/2] dm: Add no_abort_q feature flag to dm-mpath
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
Propagating queue/rotational up the stack
- From: Phillip Susi <psusi@xxxxxxxxxx>
dm_suspend will take too long?
- From: Busby <chaimvy@xxxxxxxxx>
Re: [PATCH 0/2] dm: Add no_abort_q feature flag to dm-mpath
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
Re: [PATCH 0/2] dm: Add no_abort_q feature flag to dm-mpath
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
Re: [PATCH 1/2] dm: Add feature flags to dm-mpath
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
Re: [PATCH 1/2] dm: Add feature flags to dm-mpath
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH 1/9] blk: Do not abort requests if queue is stopped
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
Re: [PATCH 1/9] blk: Do not abort requests if queue is stopped
- From: Mike Christie <michaelc@xxxxxxxxxxx>
Re: Snapshot handover working, yippee!, was Re: semop failed for cookie?
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: create lvm2 snapshot will take a long time while large IO on origin lv(till large IO ends)
- From: Busby <chaimvy@xxxxxxxxx>
Re: [PATCH 2/9] blk: In elv_abort_queue skip requests with REQ_DONTPREP set
- From: Jens Axboe <jens.axboe@xxxxxxxxxx>
Snapshot handover working, yippee!, was Re: semop failed for cookie?
- From: Douglas McClendon <dmc.fedora@xxxxxxxxxxxxxxxxxxxxxx>
Re: [PATCH 1/9] blk: Do not abort requests if queue is stopped
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
Re: Question about WWID
- From: Rodrigo Nascimento <nascimento.rp@xxxxxxxxx>
Re: Shared snapshot tests
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
[PATCH] Implement merge method for snapshot origin
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
Re: FW: Postgresql Fsync issues with LVM/DM
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
Re: [PATCH 2/9] blk: In elv_abort_queue skip requests with REQ_DONTPREP set
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
Re: [PATCH 4/9] blk: Call unprep_fn from elv_abort_queue is available
- From: Hannes Reinecke <hare@xxxxxxx>
Re: [PATCH 5/9] scsi: Add a scsi_unprep_fn
- From: Jens Axboe <jens.axboe@xxxxxxxxxx>
Re: [PATCH 2/9] blk: In elv_abort_queue skip requests with REQ_DONTPREP set
- From: Jens Axboe <jens.axboe@xxxxxxxxxx>
Re: [PATCH 9/9] scsi: Add blk_request_aborted check
- From: Hannes Reinecke <hare@xxxxxxx>
Re: [PATCH 1/9] blk: Do not abort requests if queue is stopped
- From: Jens Axboe <jens.axboe@xxxxxxxxxx>
Re: [PATCH 7/9] blk: Mark requests aborted
- From: Hannes Reinecke <hare@xxxxxxx>
Re: [PATCH 6/9] blk: Add request atomic flag for abort
- From: Hannes Reinecke <hare@xxxxxxx>
Re: [PATCH 4/9] blk: Call unprep_fn from elv_abort_queue is available
- From: Hannes Reinecke <hare@xxxxxxx>
Re: [PATCH 5/9] scsi: Add a scsi_unprep_fn
- From: Hannes Reinecke <hare@xxxxxxx>
Re: [PATCH 2/9] blk: In elv_abort_queue skip requests with REQ_DONTPREP set
- From: Hannes Reinecke <hare@xxxxxxx>
Re: [PATCH 3/9] blk: Add a unprep_rq_fn
- From: Hannes Reinecke <hare@xxxxxxx>
Re: [PATCH 1/9] blk: Do not abort requests if queue is stopped
- From: Hannes Reinecke <hare@xxxxxxx>
[PATCH 1/2] dm: Add feature flags to dm-mpath
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
[PATCH 0/2] dm: Add no_abort_q feature flag to dm-mpath
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
[PATCH 2/2] dm: Add feature flag to control call to blk_abort_queue
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
[PATCH 9/9] scsi: Add blk_request_aborted check
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
[PATCH 5/9] scsi: Add a scsi_unprep_fn
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
[PATCH 7/9] blk: Mark requests aborted
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
[PATCH 3/9] blk: Add a unprep_rq_fn
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
[PATCH 6/9] blk: Add request atomic flag for abort
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
[PATCH 4/9] blk: Call unprep_fn from elv_abort_queue is available
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
[PATCH 1/9] blk: Do not abort requests if queue is stopped
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
[PATCH 0/9] blk: scsi: blk abort queue updates
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
[PATCH 8/9] scsi: Add scsi_requeue_request function
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
[PATCH 2/9] blk: In elv_abort_queue skip requests with REQ_DONTPREP set
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
Re: Question about WWID
- From: Hannes Reinecke <hare@xxxxxxx>
Re: discard/trim support in device mapper?
- From: Andreas Beckmann <beckmann@xxxxxxxxxxxxxxxxxxx>
Re: semop failed for cookie?
- From: Douglas McClendon <dmc.fedora@xxxxxxxxxxxxxxxxxxxxxx>
Question about WWID
- From: Rodrigo Nascimento <nascimento.rp@xxxxxxxxx>
Multipath device error
- From: "Cu.auto.fw@xxxxxxxxx" <cu.auto.fw@xxxxxxxxx>
Re: create lvm2 snapshot will take a long time while large IO on origin lv(till large IO ends)
- From: Phillip Susi <psusi@xxxxxxxxxx>
Re: create lvm2 snapshot will take a long time while large IO on origin lv(till large IO ends)
- From: Busby <chaimvy@xxxxxxxxx>
Re: create lvm2 snapshot will take a long time while large IO on origin lv(till large IO ends)
- From: Phillip Susi <psusi@xxxxxxxxxx>
Re: semop failed for cookie?
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
Re: semop failed for cookie?
- From: Douglas McClendon <dmc.fedora@xxxxxxxxxxxxxxxxxxxxxx>
create lvm2 snapshot will take a long time while large IO on origin lv(till large IO ends)
- From: Busby <chaimvy@xxxxxxxxx>
Re: semop failed for cookie?
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
Re: semop failed for cookie?
- From: Douglas McClendon <dmc.fedora@xxxxxxxxxxxxxxxxxxxxxx>
bvec_merge_fn
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
Re: dm-cache module
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
Re: semop failed for cookie?
- From: Peter Rajnoha <prajnoha@xxxxxxxxxx>
Re: dm-cache module
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
Re: semop failed for cookie?
- From: Douglas McClendon <dmc.fedora@xxxxxxxxxxxxxxxxxxxxxx>
Re: dm-cache module
- From: "Olivier B." <dm.list@xxxxxxxxx>
Re: semop failed for cookie?
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
[patch 1/1] dm_ioctl: use nonseekable_open
- From: akpm@xxxxxxxxxxxxxxxxxxxx
Re: [PATCH] md: dm-crypt: Add option to re-use a new global work-queue.
- From: San Mehat <san@xxxxxxxxxx>
semop failed for cookie?
- From: Douglas McClendon <dmc.fedora@xxxxxxxxxxxxxxxxxxxxxx>
Re: Status of dm integrity checksumming features
- From: Pasi Kärkkäinen <pasik@xxxxxx>
Re: bindings file; rename WWID to mpath alias
- From: "Victoria A Smith" <vasmith@xxxxxxxxxx>
Re: bindings file; rename WWID to mpath alias
- From: brem belguebli <brem.belguebli@xxxxxxxxx>
Re: bindings file; rename WWID to mpath alias
- From: "Victoria A Smith" <vasmith@xxxxxxxxxx>
Re: bindings file; rename WWID to mpath alias
- From: brem belguebli <brem.belguebli@xxxxxxxxx>
bindings file; rename WWID to mpath alias
- From: "Victoria A Smith" <vasmith@xxxxxxxxxx>
Re: multipath-tools libmultipath/devmapper.c libmu ...
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
Re: Development problem: uninterruptable processes
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
Development problem: uninterruptable processes
- From: "Anselm Busse" <abusse@xxxxxxxxxxxxxxx>
Re: lpfc SAN/SCSI issue
- From: brem belguebli <brem.belguebli@xxxxxxxxx>
Re: multipath-tools libmultipath/config.h libmulti ...
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
multipath-tools libmultipath/config.h libmulti ...
- From: bmarzins@xxxxxxxxxxxxxx
Re: [PATCH] md: dm-crypt: Add option to re-use a new global work-queue.
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
Re: Current shared snapshots
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH] md: dm-crypt: Add option to re-use a new global work-queue.
- From: San Mehat <san@xxxxxxxxxx>
Re: [PATCH] md: dm-crypt: Add option to re-use a new global work-queue.
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: [PATCH] md: dm-crypt: Add option to re-use a new global work-queue.
- From: San Mehat <san@xxxxxxxxxx>
Re: [PATCH] md: dm-crypt: Add option to re-use a new global work-queue.
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH] md: dm-crypt: Add option to re-use a new global work-queue.
- From: San Mehat <san@xxxxxxxxxx>
Linux Plumbers Conference: Call for Tracks
- From: "Theodore Ts'o" <tytso@xxxxxxx>
Re: [patch, rfc v2] ext3/4: enhance fsync performance when using cfq
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: Shared snapshot tests
- From: Daire Byrne <daire.byrne@xxxxxxxxx>
[DOC] Some possibly deprecated info in multipath
- From: Oren Held <orenhe@xxxxxxxxxx>
Re: Current shared snapshots
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH] Just inform and dont warn when DM_DEV_REMOVE is tried on a open device
- From: Nikanth Karthikesan <knikanth@xxxxxxx>
Re: [PATCH] Just inform and dont warn when DM_DEV_REMOVE is tried on a open device
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH] Just inform and dont warn when DM_DEV_REMOVE is tried on a open device
- From: Nikanth Karthikesan <knikanth@xxxxxxx>
Current shared snapshots
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
Re: Shared snapshot tests
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
Re: high iowait problem(Bug 12309 on bugzilla.kernel.org)
- From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
multipath blocking a single path making multipath -ll , lvm commands go to D state
- From: brem belguebli <brem.belguebli@xxxxxxxxx>
Re: [PATCH] multipath_tools: add alias while printing checker_message
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
Re: multipath-tools libmultipath/devmapper.c libmu ...
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
multipath-tools libmultipath/devmapper.c libmu ...
- From: bmarzins@xxxxxxxxxxxxxx
Re: [PATCH 00/12] A dm-raid45 target implemented using md raid5.
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
Re: [PATCH 00/12] A dm-raid45 target implemented using md raid5.
- From: Neil Brown <neilb@xxxxxxx>
[PATCH] device-mapper cluster locking
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
Shared snapshot tests
- From: Daire Byrne <daire.byrne@xxxxxxxxx>
Re: [PATCH 00/12] A dm-raid45 target implemented using md raid5.
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
Re: [PATCH 00/12] A dm-raid45 target implemented using md raid5.
- From: Jeff Garzik <jeff@xxxxxxxxxx>
[PATCH 03/12] md/dm: create dm-raid456 module using md/raid5
- From: NeilBrown <neilb@xxxxxxx>
[PATCH 09/12] dm-raid456: support unplug
- From: NeilBrown <neilb@xxxxxxx>
[PATCH 07/12] md/raid5: add simple plugging infrastructure.
- From: NeilBrown <neilb@xxxxxxx>

[Index of Archives] [DM Crypt] [Fedora Desktop] [ATA RAID] [Fedora Marketing] [Fedora Packaging] [Fedora SELinux] [Yosemite Discussion] [KDE Users] [Fedora Docs]