Linux Device-Mapper Development

Thread Index

[PATCH][RFC] dm: Do not open log and cow device read-write for read-only mappings
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: [PATCH] loop: clear read-only flag in loop_clr_fd.
- From: Milan Broz <mbroz@xxxxxxxxxx>
What is the status of RAID5 support with pdc (AMD SB850 Southbridge) hardware? dmraid -rD output
- From: "rkliese@xxxxxx" <rkliese@xxxxxx>
Re: multipath: partitions are not created on IBM 1746 (SAS connection to DS3512)
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
Re: multipath: partitions are not created on IBM 1746 (SAS connection to DS3512)
- From: Peter Volkov <peter.volkov@xxxxxxxxx>
[PATCH v2] scsi_dh_rdac : Adding MODULE VERSION for rdac device handler
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
[PATCH v2] [SCSI] fix kzalloc in scsi device handler
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
[PATCH} scsi_dh_rdac: fix for lun_table update for rdac device handler
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
Re: [RFC PATCH] multipathd: use 0 for initial pg if nr_priority_groups=0
- From: Hannes Reinecke <hare@xxxxxxx>
Re: [RFC PATCH] multipathd: use 0 for initial pg if nr_priority_groups=0
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH 2/2 v2] dm mpath: allow table load with 0 priority groups
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH 2/2 v2] dm mpath: allow table load with 0 priority groups
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: dd slow while reading on multipathing, writing is fast
- From: Bart Coninckx <bart.coninckx@xxxxxxxxxx>
[PATCH]: multipath: fail path on zero size devices
- From: <Menny_Hamburger@xxxxxxxx>
Re: multipath: rdac on IBM 1746 (SAS connection to DS3512)
- From: Malahal Naineni <malahal@xxxxxxxxxx>
Re: Improving dm-mirror as a final year project
- From: Miklos Vajna <vmiklos@xxxxxx>
Re: dd slow while reading on multipathing, writing is fast
- From: "Bryn M. Reeves" <bmr@xxxxxxxxxx>
Re: dd slow while reading on multipathing, writing is fast
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
multipath: rdac on IBM 1746 (SAS connection to DS3512)
- From: Peter Volkov <peter.volkov@xxxxxxxxx>
dd slow while reading on multipathing, writing is fast
- From: bart.coninckx@xxxxxxxxxx
Re: multipath: rdac on IBM 1746 (SAS connection to DS3512)
- From: Peter Volkov <peter.volkov@xxxxxxxxx>
Re: multipath: rdac on IBM 1746 (SAS connection to DS3512)
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
Re: [PATCH 1/3] dm crypt: wipe keys string immediately after key is set
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH 3/3] dm ioctl: add data secure (bufer wipe) flag
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH 2/3] dm ioctl: tidy code for next change
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH]: scsi_dh_rdac: fix BUG_ON in get_rdac_data from within send_mode_select
- From: <Menny_Hamburger@xxxxxxxx>
Re: Using the dm tools to create a writable "mirror" of a physical disk
- From: Phillip Susi <psusi@xxxxxxxxxx>
[PATCH 3/3] dm ioctl: add data secure (bufer wipe) flag
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH 2/3] dm ioctl: tidy code for next change
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH 1/3] dm crypt: wipe keys string immediately after key is set
- From: Milan Broz <mbroz@xxxxxxxxxx>
Using the dm tools to create a writable "mirror" of a physical disk
- From: Anders Andersson <pipatron@xxxxxxxxx>
[PATCH] add -r to make resulting device read-only
- From: Ritesh Raj Sarraf <rrs@xxxxxxxxxxxxxx>
Re: [PATCH]: scsi_dh_rdac: fix BUG_ON in get_rdac_data from within send_mode_select
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
Re: Improving dm-mirror as a final year project
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
Re: [PATCH 2/2] dm mpath: allow table load with 0 priority groups
- From: Hannes Reinecke <hare@xxxxxxx>
Re: [RFC PATCH] multipathd: use 0 for initial pg if nr_priority_groups=0
- From: Hannes Reinecke <hare@xxxxxxx>
Re: Possible severe bug in the device mapper?
- From: Andreas Heinlein <aheinlein@xxxxxxx>
Re: Possible severe bug in the device mapper?
- From: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
Re: Possible severe bug in the device mapper?
- From: Joe Thornber <thornber@xxxxxxxxxx>
Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Malahal Naineni <malahal@xxxxxxxxxx>
Re: Possible severe bug in the device mapper?
- From: Andreas Heinlein <aheinlein@xxxxxxx>
Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Malahal Naineni <malahal@xxxxxxxxxx>
Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Malahal Naineni <malahal@xxxxxxxxxx>
Re: [PATCH]: scsi_dh_rdac: fix BUG_ON in get_rdac_data from within send_mode_select
- From: <Menny_Hamburger@xxxxxxxx>
Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Malahal Naineni <malahal@xxxxxxxxxx>
Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
Re: [PATCH]: scsi_dh_rdac: fix BUG_ON in get_rdac_data from within send_mode_select
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
[RFC PATCH] multipathd: use 0 for initial pg if nr_priority_groups=0 (was: Re: [PATCH 2/2] dm mpath: allow table load with 0 priority groups)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH 2/2] dm mpath: allow table load with 0 priority groups
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
[PATCH 2/2] dm mpath: allow table load with 0 priority groups
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH 1/2] dm mpath: fail message ioctl if specified path is not valid
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: Possible severe bug in the device mapper?
- From: Joe Thornber <thornber@xxxxxxxxxx>
Re: Possible severe bug in the device mapper?
- From: Milan Broz <mbroz@xxxxxxxxxx>
Possible severe bug in the device mapper?
- From: Andreas Heinlein <aheinlein@xxxxxxx>
Re: How to test the read/write flow of dm-target.
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: How to test the read/write flow of dm-target.
- From: nishant mungse <nishantmungse@xxxxxxxxx>
[PATCH]: scsi_dh_rdac: fix BUG_ON in get_rdac_data from within send_mode_select
- From: <Menny_Hamburger@xxxxxxxx>
How to find last sector of bio.
- From: nishant mungse <nishantmungse@xxxxxxxxx>
Re: How to test the read/write flow of dm-target.
- From: Malahal Naineni <malahal@xxxxxxxxxx>
Re: Doubt regarding dm-raid1
- From: Malahal Naineni <malahal@xxxxxxxxxx>
Doubt regarding dm-raid1
- From: nishant mungse <nishantmungse@xxxxxxxxx>
How to test the read/write flow of dm-target.
- From: nishant mungse <nishantmungse@xxxxxxxxx>
Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: nishant mungse <nishantmungse@xxxxxxxxx>
Re: Improving dm-mirror as a final year project
- From: nishant mungse <nishantmungse@xxxxxxxxx>
Re: Improving dm-mirror as a final year project
- From: Malahal Naineni <malahal@xxxxxxxxxx>
Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: nishant mungse <nishantmungse@xxxxxxxxx>
Re: Improving dm-mirror as a final year project
- From: nishant mungse <nishantmungse@xxxxxxxxx>
Improving dm-mirror as a final year project
- From: Miklos Vajna <vmiklos@xxxxxxxxxxxxxx>
Re: Announcement: new device-mapper thin provisioning target with infrastructure online for review
- From: Joe Thornber <thornber@xxxxxxxxxx>
Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Malahal Naineni <malahal@xxxxxxxxxx>
Improving dm-mirror as a final year project
- From: Miklos Vajna <vmiklos@xxxxxxxxxxxxxx>
Re: Announcement: new device-mapper thin provisioning target with infrastructure online for review
- From: Phillip Susi <psusi@xxxxxxxxxx>
Announcement: new device-mapper thin provisioning target with infrastructure online for review
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
Re: [PATCH wq#for-2.6.38] workqueue: use WQ_MEM_RECLAIM instead of WQ_RESCUER
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
Re: multipath - reference count on pgpath
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
Re: multipath - reference count on pgpath
- From: <Menny_Hamburger@xxxxxxxx>
Re: [PATCH] multipath: reference count on pgpath
- From: <Menny_Hamburger@xxxxxxxx>
[PATCH] multipath: reference count on pgpath
- From: <Menny_Hamburger@xxxxxxxx>
multipath - reference count on pgpath
- From: <Menny_Hamburger@xxxxxxxx>
Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Malahal Naineni <malahal@xxxxxxxxxx>
multipath-tools ./multipath.conf.defaults libm ...
- From: bmarzins@xxxxxxxxxxxxxx
Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
Re: multipath: change the DEFAULT_MINIO for the request based multipath
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH] [RFC] multipath: change the DEFAULT_MINIO for the request based multipath
- From: Hannes Reinecke <hare@xxxxxxx>
[PATCH] [RFC] multipath: change the DEFAULT_MINIO for the request based multipath
- From: Malahal Naineni <malahal@xxxxxxxxxx>
Re: [PATCH 14/49] drivers/md: Use vzalloc
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: help:"event number"
- From: tom z <maillist.tom@xxxxxxxxx>
Re: help:"event number"
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
help:"event number"
- From: tom z <maillist.tom@xxxxxxxxx>
Re: [PATCH UPDATED] block: restore multiple bd_link_disk_holder() support
- From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
Re: [PATCH UPDATED] block: restore multiple bd_link_disk_holder() support
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: "Ted Ts'o" <tytso@xxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Tejun Heo <tj@xxxxxxxxxx>
[PATCH UPDATED] block: restore multiple bd_link_disk_holder() support
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Kay Sievers <kay.sievers@xxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Karel Zak <kzak@xxxxxxxxxx>
Re: training mpath to discern between SCSI errors
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: What is the status of RAID5 support with pdc (AMD SB850 Southbridge) hardware?
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
Re: [PATCH] block: restore multiple bd_link_disk_holder() support
- From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
Re: training mpath to discern between SCSI errors
- From: Hannes Reinecke <hare@xxxxxxx>
Re: [RFC PATCH 0/3] differentiate between I/O errors
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: training mpath to discern between SCSI errors
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH] Documentation: dm-crypt: update cryptsetup homepage
- From: Jiri Kosina <jkosina@xxxxxxx>
[PATCH] Documentation: dm-crypt: update cryptsetup homepage
- From: Andrea Gelmini <andrea.gelmini@xxxxxxxxx>
Re: [PATCH] Documentation: dm-crypt: update cryptsetup homepage
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: "Ted Ts'o" <tytso@xxxxxxx>
[git pull] device-mapper patches for 2.6.38
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: NeilBrown <neilb@xxxxxxx>
Re: [PATCH] block: restore multiple bd_link_disk_holder() support
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH] block: restore multiple bd_link_disk_holder() support
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Kay Sievers <kay.sievers@xxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Karel Zak <kzak@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Kay Sievers <kay.sievers@xxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Theodore Tso <tytso@xxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Karel Zak <kzak@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Karel Zak <kzak@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
Re: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: linux-next: Tree for January 12 (dm-crypt)
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
What is the status of RAID5 support with pdc (AMD SB850 Southbridge) hardware?
- From: Mantas Kriaučiūnas <mantas@xxxxxx>
Fw: linux-next - WARNING: at fs/block_dev.c:824 bd_link_disk_holder+0x92/0x1ac()
- From: NeilBrown <neilb@xxxxxxx>
Re: linux-next: Tree for January 12 (dm-crypt)
- From: Randy Dunlap <randy.dunlap@xxxxxxxxxx>
Re: [PATCH]md:dm.c Fix warning: statement with no effect
- From: Justin Mattock <justinmattock@xxxxxxxxx>
Re: [PATCH]md:dm.c Fix warning: statement with no effect
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH v4] dm mpath: delay retry of activate_path on SCSI_DH_RETRY
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: PROBLEM: SSD access time with dm-crypt is way too high
- From: Yakov Hrebtov <hrebtov@xxxxxxxxx>
Re: [PATCH] PROBLEM: SSD access time with dm-crypt is way too high
- From: Michael Zugelder <michaelzugelder@xxxxxxxxxxxxxx>
Re: [PATCH v3 0/8] dm-raid (raid456) target
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
Re: [PATCH] PROBLEM: SSD access time with dm-crypt is way too high
- From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Re: [PATCH] PROBLEM: SSD access time with dm-crypt is way too high
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH] PROBLEM: SSD access time with dm-crypt is way too high
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
Re: trim support (discard)
- From: Jens Kasten <jens@xxxxxxxxxxxxx>
Re: [PATCH v3 0/8] dm-raid (raid456) target
- From: NeilBrown <neilb@xxxxxxx>
Re: PROBLEM: SSD access time with dm-crypt is way too high
- From: Milan Broz <mbroz@xxxxxxxxxx>
PROBLEM: SSD access time with dm-crypt is way too high
- From: Michael Zugelder <michaelzugelder@xxxxxxxxxxxxxx>
Re: trim support (discard)
- From: Milan Broz <mbroz@xxxxxxxxxx>
trim support (discard)
- From: Jens Kasten <jens@xxxxxxxxxxxxx>
Re: kobject_put vs module unload
- From: Greg KH <gregkh@xxxxxxx>
Re: kobject_put vs module unload
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
Re: kobject_put vs module unload
- From: Kay Sievers <kay.sievers@xxxxxxxx>
Re: kobject_put vs module unload
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
Re: kobject_put vs module unload
- From: Kay Sievers <kay.sievers@xxxxxxxx>
Re: [PATCH 1/6] dm-stripe: drop kstriped
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: Patch to issue pure flushes directly (Was: Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent) by fsync
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: kobject_put vs module unload
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
Re: Patch to issue pure flushes directly (Was: Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent) by fsync
- From: Christoph Hellwig <hch@xxxxxx>
Re: kobject_put vs module unload
- From: Greg KH <gregkh@xxxxxxx>
kobject_put vs module unload
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
Re: [PATCH 6/6] dm-snap-persistent: make metadata_wq multithreaded
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
Patch to issue pure flushes directly (Was: Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent) by fsync
- From: "Ted Ts'o" <tytso@xxxxxxx>
Re: [PATCH 1/6] dm-stripe: drop kstriped
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
[PATCH v2] dm log: use PTR_ERR value instead of -ENOMEM
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [patch] md/dm-log: use PTR_ERR value instead of -ENOMEM
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH v2] dm snapshot: avoid storing private suspended state
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH v2] dm: remove superfluous irq disablement in dm_request_fn
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH v3] dm mpath: delay retry of activate_path on SCSI_DH_RETRY
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Matt <jackdachef@xxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Heinz Diehl <htd@xxxxxxxxxxxxxxxxx>
[PATCH 1/3] dm crypt: add post IV call to IV generator
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH 2/3] dm crypt: add multi-key capability
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH 3/3] dm crypt: add Loop-AES IV generator
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH 0/3 v2] dm crypt: add Loop-AES compatibility mode support
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH] dm: move device check warning messages into debug level
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: [PATCH v3 0/8] dm-raid (raid456) target
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
Re: [PATCH v3 0/8] dm-raid (raid456) target
- From: Phillip Susi <psusi@xxxxxxxxxx>
Re: [PATCH v3 0/8] dm-raid (raid456) target
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
Re: [PATCH v3 0/8] dm-raid (raid456) target
- From: NeilBrown <neilb@xxxxxxx>
Re: [PATCH v3 0/8] dm-raid (raid456) target
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH] Make kcopyd merge more I/O requests
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
Re: [PATCH wq#for-2.6.38] workqueue: use WQ_MEM_RECLAIM instead of WQ_RESCUER
- From: Steven Whitehouse <swhiteho@xxxxxxxxxx>
Re: [PATCH wq#for-2.6.38] workqueue: use WQ_MEM_RECLAIM instead of WQ_RESCUER
- From: Tejun Heo <tj@xxxxxxxxxx>
[PATCH wq#for-2.6.38] workqueue: use WQ_MEM_RECLAIM instead of WQ_RESCUER
- From: Tejun Heo <tj@xxxxxxxxxx>
Refcounting (and other) questions
- From: Kent Overstreet <kent.overstreet@xxxxxxxxx>
[RFC][PATCH] dm: improve read performance
- From: Mustafa Mesanovic <mume@xxxxxxxxxxxxxxxxxx>
Re: [RFC][PATCH] dm: improve read performance
- From: Mustafa Mesanovic <mume@xxxxxxxxxxxxxxxxxx>
Re: [RFC][PATCH] dm: improve read performance
- From: Neil Brown <neilb@xxxxxxx>
[PATCH 4/7] dm crypt: remove unused compatible table output
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH 6/7] [RFC]dm crypt: add multi-key capability
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH 7/7] [RFC]dm crypt: add loop-aes LMK IV generator
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH 2/7] dm crypt: remove redundant setkey call
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH 5/7] dm crypt: redefine IV generator function and add post IV call
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH 3/7] dm crypt: set key size early
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH 0/7] dm crypt fixes and loop-aes mode support
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH 1/7] dm crypt: fix per cpu struct dereference in destructor
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH v3 3/8] md/raid5: use sysfs_notify_dirent_safe to avoid NULL pointer
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH v3 0/8] dm-raid (raid456) target
- From: Neil Brown <neilb@xxxxxxx>
[PATCH v3 4/8] dm raid: skeleton raid456 target support
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH v3 2/8] md/bitmap: use DIV_ROUND_UP in bitmap_init_from_disk
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH v3 7/8] dm raid: add iterate_devices and io_hints functions
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH v3 6/8] dm: per-target unplug callback support
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH v3 5/8] dm: introduce target callbacks and congestion callback
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH v3 8/8] dm raid: add suspend and resume functions
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH v3 1/8] md/bitmap: revert dm-dirty-log preparation
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH v3 0/8] dm-raid (raid456) target
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: dm: update workqueue usages
- From: Tejun Heo <tj@xxxxxxxxxx>
BUG after md/raid10:md0: not enough operational mirrors.
- From: Ilia Mirkin <imirkin@xxxxxxxxxxxx>
Re: dm: update workqueue usages
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[ANNOUNCE] cryptsetup 1.2.0
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH] multipath: add allow users to set revision in multipath.conf
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
mpath_ctl syntax
- From: Miles Taylor <Miles.Taylor@xxxxxxxxxxxx>
Trying to figure out how/whether to use device mapper with bcache
- From: Kent Overstreet <kent.overstreet@xxxxxxxxx>
Re: reproducer for DM on MD flush deadlock? (was: Re: [PULL REQUEST] md bug fixes)
- From: Neil Brown <neilb@xxxxxxx>
reproducer for DM on MD flush deadlock? (was: Re: [PULL REQUEST] md bug fixes)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH 1/1] RFC: scsi/dm-mpath: return -EACCES on reservation conflict
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH v3][SCSI] scsi_dh: propagate SCSI device deletion
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
Re: training mpath to discern between SCSI errors
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH][rfc] md: Close mem leak in userspace_ctr()
- From: Jesper Juhl <jj@xxxxxxxxxxxxx>
Re: training mpath to discern between SCSI errors
- From: Hannes Reinecke <hare@xxxxxxx>
Re: [PATCH for-2.6.37] block: max hardware sectors limit wrapper
- From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
Re: [PATCH for-2.6.37] block: max hardware sectors limit wrapper
- From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
[PATCH v3][SCSI] scsi_dh: propagate SCSI device deletion
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH v2][SCSI] scsi_dh: propagate SCSI device deletion
- From: <Menny_Hamburger@xxxxxxxx>
Re: [PATCH v2][SCSI] scsi_dh: propagate SCSI device deletion
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH v2][SCSI] scsi_dh: propagate SCSI device deletion
- From: <Menny_Hamburger@xxxxxxxx>
[PATCH v2][SCSI] scsi_dh: propagate SCSI device deletion
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [Patch 2 of 2]: scsi-dh + dm-mpath: propagate SCSI device deletion to multipath
- From: <Menny_Hamburger@xxxxxxxx>
Re: [Patch 2 of 2]: scsi-dh + dm-mpath: propagate SCSI device deletion to multipath
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
Re: [Patch 2 of 2]: scsi-dh + dm-mpath: propagate SCSI device deletion to multipath
- From: <Menny_Hamburger@xxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Dave Chinner <david@xxxxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Matt <jackdachef@xxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Matt <jackdachef@xxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Matt <jackdachef@xxxxxxxxx>
Re: [Patch 2 of 2]: scsi-dh + dm-mpath: propagate SCSI device deletion to multipath
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [Patch 1 of 2]: scsi-dh + dm-mpath: propagate SCSI device deletion to multipath
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
Re: [Patch 2 of 2]: scsi-dh + dm-mpath: propagate SCSI device deletion to multipath
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
[Patch 2 of 2]: scsi-dh + dm-mpath: propagate SCSI device deletion to multipath
- From: <Menny_Hamburger@xxxxxxxx>
[Patch 1 of 2]: scsi-dh + dm-mpath: propagate SCSI device deletion to multipath
- From: <Menny_Hamburger@xxxxxxxx>
Re: [PATCH 1/6] dm-stripe: drop kstriped
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH 1/6] dm-stripe: drop kstriped
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH][rfc] md: Close mem leak in userspace_ctr()
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH 4 of 8] dm raid seed module
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 8 of 8] dm raid suspend and resume fns
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 7 of 8] dm raid iterate_devices and io_hints
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 6 of 8] dm unplug callback
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 3 of 8] md fix null pointer deref
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 2 of 8] md minor updates
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 1 of 8] md backout dm dirty log
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 5 of 8] dm target callbacks and congestion fn
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 0 of 8] DM RAID: a wrapper target for MD RAID456 (skeleton)
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
Re: [PATCH 1/1]: missing call to pg_init_done causes I/O to be hung forever
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
Re: dm: update workqueue usages
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: dm: update workqueue usages
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCHSET] dm: update workqueue usages
- From: Tejun Heo <tj@xxxxxxxxxx>
[PATCH][rfc] md: Close mem leak in userspace_ctr()
- From: Jesper Juhl <jj@xxxxxxxxxxxxx>
Re: [PATCHSET] dm: update workqueue usages
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: [PATCHSET] dm: update workqueue usages
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
Re: [PATCH 1/1]: missing call to pg_init_done causes I/O to be hung forever
- From: <Menny_Hamburger@xxxxxxxx>
Re: [PATCH 1/1]: missing call to pg_init_done causes I/O to be hung forever
- From: <Menny_Hamburger@xxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: [PATCH 1/1]: missing call to pg_init_done causes I/O to be hung forever
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
dm-devel] [PATCH 1/1]: dm+dh: missing call to pg_init_done causes I/O to be hung forever
- From: <Menny_Hamburger@xxxxxxxx>
[PATCH 1/1]: missing call to pg_init_done causes I/O to be hung forever
- From: <Menny_Hamburger@xxxxxxxx>
Re: rdac.c patch not quite right.
- From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: "Ted Ts'o" <tytso@xxxxxxx>
Re: [PATCHSET] dm: update workqueue usages
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH 5/6] dm: use non-reentrant workqueues if equivalent
- From: Tejun Heo <tj@xxxxxxxxxx>
[PATCH 4/6] dm: don't use flush_scheduled_work()
- From: Tejun Heo <tj@xxxxxxxxxx>
[PATCH 6/6] dm-snap-persistent: make metadata_wq multithreaded
- From: Tejun Heo <tj@xxxxxxxxxx>
[PATCH 1/6] dm-stripe: drop kstriped
- From: Tejun Heo <tj@xxxxxxxxxx>
[PATCH 3/6] dm-snap: convert to alloc[_ordered]_workqueue()
- From: Tejun Heo <tj@xxxxxxxxxx>
[PATCHSET] dm: update workqueue usages
- From: Tejun Heo <tj@xxxxxxxxxx>
[PATCH 2/6] dm-snap: kill unused dm_snapshot->queued_bios_work and ksnapd
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: "Ted Ts'o" <tytso@xxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: "Ted Ts'o" <tytso@xxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: "Ted Ts'o" <tytso@xxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: [RFC PATCH 0/3] differentiate between I/O errors
- From: Malahal Naineni <malahal@xxxxxxxxxx>
[PATCH <missing> of 8: MD new mddev flag value
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 8 of 8] dm raid suspend and resume fns
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 6 of 8] dm unplug callback
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 7 of 8] dm raid iterate_devices and io_hints
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 5 of 8] dm target callbacks and congestion fn
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 4 of 8] dm raid seed module
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 3 of 8] md fix null pointer deref
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 2 of 8] md minor updates
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 1 of 8] md backout dm dirty log
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 0 of 8] DM RAID: a wrapper target for MD RAID456 (skeleton)
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Mike Fedyk <mfedyk@xxxxxxxxxxxxx>
Possible kpartx bug investigation/report
- From: Tarcisio Fedrizzi <tarcisio.fedrizzi@xxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: "Ted Ts'o" <tytso@xxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Matt <jackdachef@xxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: "Ted Ts'o" <tytso@xxxxxxx>
[RESEND][PATCH v2 1/4] dm log userspace: trap all errors from failed log construction
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: "Ted Ts'o" <tytso@xxxxxxx>
Re: rdac.c patch not quite right.
- From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxx>
Re: rdac.c patch not quite right.
- From: Malahal Naineni <malahal@xxxxxxxxxx>
Re: rdac.c patch not quite right.
- From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxx>
Re: rdac.c patch not quite right.
- From: Malahal Naineni <malahal@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
[PATCH v2 3/3] block: improve detail in I/O error messages
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
Re: [RFC PATCH 3/3] block: improve detail in I/O error messages
- From: Sergei Shtylyov <sshtylyov@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: rdac.c patch not quite right.
- From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
[RFC PATCH 3/3] block: improve detail in I/O error messages
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[RFC PATCH 0/3] differentiate between I/O errors
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[RFC PATCH v2 1/3] scsi: Detailed I/O errors
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[RFC PATCH v2 2/3] dm mpath: propagate target errors immediately
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH] multipath: add find_multipaths feature.
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
Re: [stable] QUEUE_FLAG_CLUSTER?
- From: Greg KH <greg@xxxxxxxxx>
Re: rdac.c patch not quite right.
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: "Ted Ts'o" <tytso@xxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Chris Mason <chris.mason@xxxxxxxxxx>
multipath-tools/multipathd main.c
- From: bmarzins@xxxxxxxxxxxxxx
Re: multipathing in debian lenny with sychronized data between 2 servers
- From: Oliver Rojo <orojo.horus@xxxxxxxxx>
Re: multipathing in debian lenny with sychronized data between 2 servers
- From: Oliver Rojo <orojo.horus@xxxxxxxxx>
Re: multipathing in debian lenny with sychronized data between 2 servers
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
[PATCH for-2.6.37] block: max hardware sectors limit wrapper
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
multipathing in debian lenny with sychronized data between 2 servers
- From: Oliver Rojo <orojo.horus@xxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Daniel J Blueman <daniel.blueman@xxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Heinz Diehl <htd@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Valdis.Kletnieks@xxxxxx
Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Heinz Diehl <htd@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Matt <jackdachef@xxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: "Ted Ts'o" <tytso@xxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Matt <jackdachef@xxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Matt <jackdachef@xxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Theodore Tso <tytso@xxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Heinz Diehl <htd@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption?
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Heinz Diehl <htd@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Matt <jackdachef@xxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Matt <jackdachef@xxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Heinz Diehl <htd@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: dm: check max_sectors in dm_merge_bvec (was: Re: dm: max_segments=1 if merge_bvec_fn is not supported)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Matt <jackdachef@xxxxxxxxx>
Re: [PATCH] dm: check max_sectors in dm_merge_bvec (was: Re: dm: max_segments=1 if merge_bvec_fn is not supported)
- From: Lars Ellenberg <lars.ellenberg@xxxxxxxxxx>
[PATCH] dm: check max_sectors in dm_merge_bvec (was: Re: dm: max_segments=1 if merge_bvec_fn is not supported)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH] multipath: make "show config" show the whole config.
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
[PATCH] multipath: standardize on path_selector
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
[PATCH] multipath: update multipathd man page
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
[PATCH v2 4/4] dm log userspace: add version number to communication structure
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH v2 3/4] dm log userspace: group clear and mark requests
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH v2 2/4] dm log userspace: split flush queue
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH v2 0/4] dm log userspace: a fix and other improvements
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH v2 1/4] dm log userspace: trap all errors from failed log construction
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
How about adding an include directive in multipath.conf file?
- From: Don Hoover <dxh@xxxxxxxxx>
Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram
- From: Nick Piggin <npiggin@xxxxxxxxx>
[PATCH 14 of 15] md new superblock type
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 15 of 15] md add bitmap support
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 13 of 15] dm raid allow metadata devices
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 12 of 15] md separate meta and data devs
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 11 of 15] md new param to_sync_page_io
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 9 of 15] dm raid message fn
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 10 of 15] md new param to calc_dev_sboffset
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 4 of 15] dm raid seed module
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 1 of 15] md backout dm dirty log
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 7 of 15] dm raid iterate_devices and io_hints
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 6 of 15] dm unplug callback
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 5 of 15] dm target callbacks and congestion fn
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 8 of 15] dm raid suspend and resume fns
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 2 of 15] md minor updates
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 3 of 15] md fix null pointer deref
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 0 of 15] DM RAID: a wrapper target for MD RAID456
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram
- From: "Ted Ts'o" <tytso@xxxxxxx>
Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Matt <jackdachef@xxxxxxxxx>
Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH 1/4] block: Measure flush round-trip times and report average value
- From: Lukas Czerner <lczerner@xxxxxxxxxx>
hunt for 2.6.37 dm-crypt+ext4 corruption? (was: Re: dm-crypt barrier support is effective)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: dm-crypt barrier support is effective
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: dm-crypt barrier support is effective
- From: Jon Nelson <jnelson@xxxxxxxxxxx>
Re: dm-crypt barrier support is effective
- From: Heinz Diehl <htd@xxxxxxxxxx>
Re: block: Deprecate QUEUE_FLAG_CLUSTER and use queue_limits instead
- From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
Re: dm-crypt barrier support is effective
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: dm-crypt barrier support is effective
- From: Matt <jackdachef@xxxxxxxxx>
Re: dm-crypt barrier support is effective
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: dm-crypt barrier support is effective
- From: Matt <jackdachef@xxxxxxxxx>
Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: Mingming Cao <cmm@xxxxxxxxxx>
Re: ioctl HDIO_GETGEO to device mapper devpath
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
Re: training mpath to discern between SCSI errors
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: QUEUE_FLAG_CLUSTER?
- From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
multipath-tools/libmultipath discovery.c switc ...
- From: bmarzins@xxxxxxxxxxxxxx
Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: Christoph Hellwig <hch@xxxxxx>
Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: Christoph Hellwig <hch@xxxxxx>
Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: Ric Wheeler <rwheeler@xxxxxxxxxx>
rdac.c patch not quite right.
- From: Chaskiel Grundman <cg2v@xxxxxxxxxxxxxx>
Re: ioctl HDIO_GETGEO to device mapper devpath
- From: Hannes Reinecke <hare@xxxxxxx>
Re: [PATCH 3/4] dm: Compute average flush time from component devices
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: Neil Brown <neilb@xxxxxxx>
Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: Ric Wheeler <rwheeler@xxxxxxxxxx>
Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: Neil Brown <neilb@xxxxxxx>
Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
Re: Q: md-RAID1 creation with I/O error (attempt to access beyond end of device)
- From: Neil Brown <neilb@xxxxxxx>
Re: [PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: Ric Wheeler <rwheeler@xxxxxxxxxx>
[PATCH] dm crypt: use IO thread for reads only if mempool is exhausted
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH] dm crypt: scale to multiple CPUs
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH] dm: remove dm_mutex (after bkl conversion)
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: [Multipath DOCS] Some possibly deprecated info
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
[PATCH 4/4] ext4: Coordinate data-only flush requests sent by fsync
- From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
[PATCH v6 0/4] ext4: Coordinate data-only flush requests sent by fsync
- From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
[PATCH 3/4] dm: Compute average flush time from component devices
- From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
[PATCH 1/4] block: Measure flush round-trip times and report average value
- From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
[PATCH 2/4] md: Compute average flush time from component devices
- From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
ioctl HDIO_GETGEO to device mapper devpath
- From: Santosh Sarangi <santosh.sarangi1@xxxxxxxxx>
[Multipath DOCS] Some possibly deprecated info
- From: Oren Held <orenhe@xxxxxxxxxx>
discard/trim support in device mapper?
- From: Andreas Beckmann <beckmann@xxxxxxxxxxxxxxxxxxx>
Re: Q: md-RAID1 creation with I/O error (attempt to access beyond end of device)
- From: Rahsaan Page <rahsaan.page@xxxxxxxxx>
Antw: Re: Q: md-RAID1 creation with I/O error (attempt to access beyond end of device)
- From: "Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>
Q: md-RAID1 creation with I/O error (attempt to access beyond end of device)
- From: "Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>
/usr/src/linux/drivers/md/bitmap.c: strange rounding lines 855-875
- From: "Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>
Re: dm-crypt barrier support is effective (was: Re: DM-CRYPT: Scale to multiple CPUs v3 on 2.6.37-rc* ?)
- From: Matt <jackdachef@xxxxxxxxx>
Re: scsi_dh_emc vs scsi_dh_alua in RHEL5.5
- From: <wayne.berthiaume@xxxxxxx>
Re: Linux 2.6.36-rc7
- From: Torsten Kaiser <just.for.lkml@xxxxxxxxxxxxxx>
Re: dm-crypt barrier support is effective
- From: Matt <jackdachef@xxxxxxxxx>
Re: [PATCH 1/5] mtd: fix bdev exclusive open bugs in block2mtd::add_device()
- From: Artem Bityutskiy <dedekind1@xxxxxxxxx>
Re: dm-crypt barrier support is effective
- From: Heinz Diehl <htd@xxxxxxxxxx>
Re: [PATCH UPDATED 1/5] mtd: fix bdev exclusive open bugs in block2mtd::add_device()
- From: Artem Bityutskiy <dedekind1@xxxxxxxxx>
Re: QUEUE_FLAG_CLUSTER?
- From: "Ed Lin - PTU" <ed.lin@xxxxxxxxxxx>
Re: [PATCH 1/5] mtd: fix bdev exclusive open bugs in block2mtd::add_device()
- From: Artem Bityutskiy <dedekind1@xxxxxxxxx>
[PATCH] scsi: Set queue limits no_cluster for stacked devices
- From: "Ed Lin" <ed.lin@xxxxxxxxxxx>
Re: data corruption with stex (Promise HW-Raid) driver and device-mapper
- From: "Ed Lin - PTU" <ed.lin@xxxxxxxxxxx>
multipath-tools comments and licensing status?
- From: Diego Elio Pettenò <flameeyes@xxxxxxxxx>
raid0 and discard/trim - current state?
- From: DagB <dag@xxxxxxxxx>
Re: raid0 and discard/trim - current state?
- From: DagB <dag@xxxxxxxxx>
Problem with creating LV - device too small for target
- From: Artur Piechocki <artur.piechocki@xxxxxxxxxx>
scsi_dh_emc vs scsi_dh_alua in RHEL5.5
- From: Brian De Wolf <bldewolf@xxxxxxxxxxxxx>
Problem with creating LV - device too small for target
- From: Artur Piechocki <artur.piechocki@xxxxxxxxxx>
[PATCH] libmultipath: fix snprintf buffer overflows
- From: Tim Harder <radhermit@xxxxxxxxxx>
Re: [PATCH] libmultipath: fix snprintf buffer overflows
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
Re: [PATCHSET] block: clean up bdev claim/release handling
- From: Jens Axboe <axboe@xxxxxxxxx>
Re: [PATCHSET] block: clean up bdev claim/release handling
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: block: Deprecate QUEUE_FLAG_CLUSTER and use queue_limits instead
- From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
Re: block: Deprecate QUEUE_FLAG_CLUSTER and use queue_limits instead
- From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
Re: block: Deprecate QUEUE_FLAG_CLUSTER and use queue_limits instead
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: block: Deprecate QUEUE_FLAG_CLUSTER and use queue_limits instead
- From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
Re: block: Deprecate QUEUE_FLAG_CLUSTER and use queue_limits instead
- From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
block: Deprecate QUEUE_FLAG_CLUSTER and use queue_limits instead
- From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
Re: QUEUE_FLAG_CLUSTER?
- From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
Re: Bug#604049: linux-image-2.6.32-5-amd64: data corruption with promise stex driver and use of device-mapper layers (lvm/dm-crypt/..)
- From: Ben Hutchings <ben@xxxxxxxxxxxxxxx>
Re: Bug#604049: linux-image-2.6.32-5-amd64: data corruption with promise stex driver and use of device-mapper layers (lvm/dm-crypt/..)
- From: "Ed Lin - PTU" <ed.lin@xxxxxxxxxxx>
QUEUE_FLAG_CLUSTER?
- From: "Ed Lin - PTU" <ed.lin@xxxxxxxxxxx>
Re: data corruption with stex (Promise HW-Raid) driver and device-mapper
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH] dm raid1: support discard
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH v2] dm kcopyd: remove SYNC from flags used in dm_io_request
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH v2] dm kcopyd: delay unplug of the queues
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH v3 19/22] dm: use little-endian bit operations
- From: Akinobu Mita <akinobu.mita@xxxxxxxxx>
[PATCH v2] dm mpath: revert "dm: Call blk_abort_queue on failed paths"
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: dm-kcopyd: Delayed unplug of the queues
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
Re: Remove BIO_RW_SYNCIO flag from kcopyd
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
Re: dm-kcopyd: Delayed unplug of the queues
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: Remove BIO_RW_SYNCIO flag from kcopyd
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH] multipath: add checker_timeout default config option
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
[PATCH] multipath: update default configurations
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
Re: [RFC] training mpath to discern between SCSI errors
- From: Malahal Naineni <malahal@xxxxxxxxxx>
[PATCH 6 of 9] dm unplug callback
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 5 of 9] dm target callbacks and congestion fn
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 9 of 9] dm raid message fn
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 7 of 9] dm raid iterate_devices and io_hints
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 8 of 9] dm raid suspend and resume fns
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 4 of 9] dm raid seed module
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 3 of 9] md fix null pointer deref
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 2 of 9] md minor updates
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 1 of 9] md backout dm dirty log
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH 0 of 9] DM RAID: a wrapper target for MD RAID456
- From: Jonathan Brassow <jbrassow@xxxxxxxxxx>
[PATCH] dm mpath: disable call to blk_abort_queue and related code
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH v5] dm mpath: avoid call to blk_abort_queue by default
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
Re: [PATCH v5] dm mpath: avoid call to blk_abort_queue by default
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
[PATCH v5] dm mpath: avoid call to blk_abort_queue by default
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: (no subject)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH v4] dm mpath: avoid call to blk_abort_queue by default
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
(no subject)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH] multipath: add find_multipaths feature.
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
[PATCH v3] dm mpath: add feature flag to control call to blk_abort_queue
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH v2] dm mpath: add feature flag to control call to blk_abort_queue
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: kernel update and dmraid causing grub errors
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
Split load balanced paths into two groups
- From: Jonas Björklund <jonas@xxxxxxxxxxxx>
Re: [PATCH v2] dm mpath: add feature flag to control call to blk_abort_queue
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
[PATCH v2] dm mpath: add feature flag to control call to blk_abort_queue
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: block_abort_queue (blk_abort_request) racing with scsi_request_fn
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
Re: [PATCH] multipath: add find_multipaths feature.
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
[PATCH] multipath: add find_multipaths feature.
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
Re: block_abort_queue (blk_abort_request) racing with scsi_request_fn
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH v2] block: rename trace_block_remap to trace_block_bio_remap
- From: Jens Axboe <jaxboe@xxxxxxxxxxxx>
Re: [PATCH v2] block: rename trace_block_remap to trace_block_bio_remap
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH v2] block: rename trace_block_remap to trace_block_bio_remap
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: dm-crypt barrier support is effective
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: dm-crypt barrier support is effective
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH] multipath: clean up path orphaning and adoption
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
dm-crypt barrier support is effective (was: Re: DM-CRYPT: Scale to multiple CPUs v3 on 2.6.37-rc* ?)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH UPDATED 1/5] mtd: fix bdev exclusive open bugs in block2mtd::add_device()
- From: Tejun Heo <tj@xxxxxxxxxx>
[PATCH UPDATED 1/5] mtd: fix bdev exclusive open bugs in block2mtd::add_device()
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: [PATCH 1/5] mtd: fix bdev exclusive open bugs in block2mtd::add_device()
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: [PATCH v5] dm crypt: scale to multiple CPUs
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
multipath-tools ./multipath.conf.defaults libm ...
- From: bmarzins@xxxxxxxxxxxxxx
[PATCH v5] dm crypt: scale to multiple CPUs
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: block_abort_queue (blk_abort_request) racing with scsi_request_fn
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
Re: [PATCHSET] block: clean up bdev claim/release handling
- From: Tejun Heo <tj@xxxxxxxxxx>
[PATCH 7/5] block: clean up blkdev_get() wrappers and their users
- From: Tejun Heo <tj@xxxxxxxxxx>
[PATCH 6/5] block: check bdev_read_only() from blkdev_get()
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: block_abort_queue (blk_abort_request) racing with scsi_request_fn
- From: Mike Christie <michaelc@xxxxxxxxxxx>
[PATCH] multipath: sort all pathgroups by priority
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
Re: block_abort_queue (blk_abort_request) racing with scsi_request_fn
- From: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx>
Re: block_abort_queue (blk_abort_request) racing with scsi_request_fn
- From: Mike Christie <michaelc@xxxxxxxxxxx>
Re: block_abort_queue (blk_abort_request) racing with scsi_request_fn
- From: Mike Christie <michaelc@xxxxxxxxxxx>
Re: kernel update and dmraid causing grub errors
- From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
Re: kernel update and dmraid causing grub errors
- From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
Re: [PATCH 4/5] block: make blkdev_get/put() handle exclusive access
- From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Re: [PATCH 4/5] block: make blkdev_get/put() handle exclusive access
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: [PATCH 4/5] block: make blkdev_get/put() handle exclusive access
- From: Tejun Heo <tj@xxxxxxxxxx>
[PATCH] [RFC] multipath: multipath command pathgroup compare problem
- From: Malahal Naineni <malahal@xxxxxxxxxx>
Re: DM-CRYPT: Scale to multiple CPUs v3 on 2.6.37-rc* ?
- From: Chris Mason <chris.mason@xxxxxxxxxx>
Re: DM-CRYPT: Scale to multiple CPUs v3 on 2.6.37-rc* ?
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: RFC: multipath IO multiplex
- From: Lars Marowsky-Bree <lmb@xxxxxxxxxx>
Re: [PATCH] DM-CRYPT: Scale to multiple CPUs v3 on 2.6.37-rc* ?
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
Re: RFC: multipath IO multiplex
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
Re: RFC: multipath IO multiplex
- From: Hannes Reinecke <hare@xxxxxxx>
Re: RFC: multipath IO multiplex
- From: Lars Marowsky-Bree <lmb@xxxxxxxxxx>
Re: RFC: multipath IO multiplex
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
Re: RFC: multipath IO multiplex
- From: Lars Marowsky-Bree <lmb@xxxxxxxxxx>
Re: [PATCH] DM-CRYPT: Scale to multiple CPUs v3 on 2.6.37-rc* ?
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
Re: [PATCH] DM-CRYPT: Scale to multiple CPUs v3 on 2.6.37-rc* ?
- From: Matt <jackdachef@xxxxxxxxx>
Re: [PATCH] DM-CRYPT: Scale to multiple CPUs v3 on 2.6.37-rc* ?
- From: Matt <jackdachef@xxxxxxxxx>
Re: [PATCH] DM-CRYPT: Scale to multiple CPUs v3 on 2.6.37-rc* ?
- From: Heinz Diehl <htd@xxxxxxxxxx>
Re: [PATCH] DM-CRYPT: Scale to multiple CPUs v3 on 2.6.37-rc* ?
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: [PATCH] DM-CRYPT: Scale to multiple CPUs v3 on 2.6.37-rc* ?
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
Re: CFQ and dm-crypt
- From: Richard Kralovic <Richard.Kralovic@xxxxxxxxxxxxxxxxx>
Re: CFQ and dm-crypt
- From: Richard Kralovic <Richard.Kralovic@xxxxxxxxxxxxxxxxx>
[PATCH] DM-CRYPT: Scale to multiple CPUs v3 on 2.6.37-rc* ?
- From: Matt <jackdachef@xxxxxxxxx>
Re: [PATCH] DM-CRYPT: Scale to multiple CPUs v3 on 2.6.37-rc* ?
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: RFC: multipath IO multiplex
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
Re: RFC: multipath IO multiplex
- From: Lars Marowsky-Bree <lmb@xxxxxxxxxx>
Re: RFC: multipath IO multiplex
- From: Lars Marowsky-Bree <lmb@xxxxxxxxxx>
sysstat metrics on a mirrored logical volume
- From: Brem Belguebli <brem.belguebli@xxxxxxxxx>
Re: RFC: multipath IO multiplex
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
Re: RFC: multipath IO multiplex
- From: Neil Brown <neilb@xxxxxxx>
Re: introduce dm-snap-mv
- From: Daniel Phillips <phillips@xxxxxxxxx>
RFC: multipath IO multiplex
- From: Lars Marowsky-Bree <lmb@xxxxxxxxxx>
Re: [PATCH] multipath: fix multipath locking
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
Re: [PATCH] multipath: fix multipath locking
- From: Malahal Naineni <malahal@xxxxxxxxxx>
[PATCH] multipath: fix multipath locking
- From: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
[PATCH 14/49] drivers/md: Use vzalloc
- From: Joe Perches <joe@xxxxxxxxxxx>
[PATCH 00/49] Use vzalloc not vmalloc/kmemset
- From: Joe Perches <joe@xxxxxxxxxxx>
Re: kernel update and dmraid causing grub errors
- From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
Re: scsi_dh_rdac: Changing the memory allocation flag from GFP_KERNEL to GFP_NOIO
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
Re: scsi_dh_rdac: Changing the memory allocation flag from GFP_KERNEL to GFP_NOIO
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH 3/5] block: simplify holder symlink handling
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH 4/5] block: make blkdev_get/put() handle exclusive access
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: [PATCH 4/5] block: make blkdev_get/put() handle exclusive access
- From: Jan Kara <jack@xxxxxxx>
Re: kernel update and dmraid causing grub errors
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
Re: cmwq and dm-crypt devices?
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
Re: kernel update and dmraid causing grub errors
- From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
Re: kernel update and dmraid causing grub errors
- From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
Re: RDAC path checker status change messages
- From: Christophe Varoqui <christophe.varoqui@xxxxxxxxx>
[PATCH v2] block: rename trace_block_remap to trace_block_bio_remap
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: RDAC path checker status change messages
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: Memory leak if failed to do RTPG.
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
[PATCH] dm: remove extra locking when changing device size
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: cmwq and dm-crypt devices?
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: cmwq and dm-crypt devices?
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: cmwq and dm-crypt devices?
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
Re: [PATCH 4/5] block: make blkdev_get/put() handle exclusive access
- From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Re: [Drbd-dev] [PATCHSET] block: clean up bdev claim/release handling
- From: Philipp Reisner <philipp.reisner@xxxxxxxxxx>
Re: cmwq and dm-crypt devices?
- From: Alasdair G Kergon <agk@xxxxxxxxxx>
Re: cmwq and dm-crypt devices?
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: cmwq and dm-crypt devices?
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
Re: kernel update and dmraid causing grub errors
- From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
Re: cmwq and dm-crypt devices?
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: cmwq and dm-crypt devices?
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
Re: cmwq and dm-crypt devices?
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: Can't seem to set features=1 queue_if_no_path
- From: "Moger, Babu" <Babu.Moger@xxxxxxx>
cmwq and dm-crypt devices? (was: Re: md: dm-crypt: Add option to re-use a new global work-queue.)
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: dm mpath: delay retry activate_path on SCSI_DH_RETRY
- From: Mike Christie <mchristi@xxxxxxxxxx>
Re: block: QUEUE_FLAG_CLUSTER and no_cluster are NOT in sync
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: dm mpath: delay retry activate_path on SCSI_DH_RETRY
- From: Chandra Seetharaman <sekharan@xxxxxxxxxx>
Re: dm mpath: delay retry activate_path on SCSI_DH_RETRY
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Can't seem to set features=1 queue_if_no_path
- From: Nuno Fernandes <npf-mlists@xxxxxxxxxxx>
Re: dm: Fix possible NULL dereferences
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
kernel update and dmraid causing grub errors
- From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
Re: [PATCHSET] block: clean up bdev claim/release handling
- From: Neil Brown <neilb@xxxxxxx>
[PATCHSET] block: clean up bdev claim/release handling
- From: Tejun Heo <tj@xxxxxxxxxx>
[PATCH 3/5] block: simplify holder symlink handling
- From: Tejun Heo <tj@xxxxxxxxxx>
[PATCH 4/5] block: make blkdev_get/put() handle exclusive access
- From: Tejun Heo <tj@xxxxxxxxxx>
[PATCH 5/5] block: reorganize claim/release implementation
- From: Tejun Heo <tj@xxxxxxxxxx>
[PATCH 1/5] mtd: fix bdev exclusive open bugs in block2mtd::add_device()
- From: Tejun Heo <tj@xxxxxxxxxx>
[PATCH 2/5] btrfs: close_bdev_exclusive() should use the same @flags as the matching open_bdev_exclusive()
- From: Tejun Heo <tj@xxxxxxxxxx>
Re: dm: lock bd_mutex when setting device size
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: dm: lock bd_mutex when setting device size
- From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
dm: lock bd_mutex when setting device size
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: dm: use revalidate_disk to update device size after set_capacity
- From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
Re: dm: use revalidate_disk to update device size after set_capacity
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: dm: use revalidate_disk to update device size after set_capacity
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
Re: dm: use revalidate_disk to update device size after set_capacity
- From: "Jun'ichi Nomura" <j-nomura@xxxxxxxxxxxxx>
Re: dm: use revalidate_disk to update device size after set_capacity
- From: Mike Snitzer <snitzer@xxxxxxxxxx>
multipath-tools libcheckers/directio.c libchec ...
- From: bmarzins@xxxxxxxxxxxxxx
Re: unmapping luns doesn't work (good)
- From: Rudy Gevaert <Rudy.Gevaert@xxxxxxxx>
Re: [RESUBMIT][Patch] scsi_dh_rdac: retry IO for 06/3f/03 in rdac_check_sense fn
- From: <Shyam_Iyer@xxxxxxxx>
Re: [RESUBMIT][Patch] scsi_dh_rdac: retry IO for 06/3f/03 in rdac_check_sense fn
- From: James Bottomley <James.Bottomley@xxxxxxx>
Re: [RESUBMIT][Patch] scsi_dh_rdac: retry IO for 06/3f/03 in rdac_check_sense fn
- From: <Shyam_Iyer@xxxxxxxx>
Re: [RESUBMIT][Patch] scsi_dh_rdac: retry IO for 06/3f/03 in rdac_check_sense fn
- From: James Bottomley <James.Bottomley@xxxxxxx>
Re: [RESUBMIT][Patch] scsi_dh_rdac: retry IO for 06/3f/03 in rdac_check_sense fn
- From: Mike Christie <michaelc@xxxxxxxxxxx>
Re: [RESUBMIT][Patch] scsi_dh_rdac: retry IO for 06/3f/03 in rdac_check_sense fn
- From: Malahal Naineni <malahal@xxxxxxxxxx>
[RESUBMIT][Patch] scsi_dh_rdac: retry IO for 06/3f/03 in rdac_check_sense fn
- From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxx>
Re: CFQ and dm-crypt
- From: Vivek Goyal <vgoyal@xxxxxxxxxx>
Re: CFQ and dm-crypt
- From: Vivek Goyal <vgoyal@xxxxxxxxxx>
Re: CFQ and dm-crypt
- From: Jeff Moyer <jmoyer@xxxxxxxxxx>
Re: CFQ and dm-crypt
- From: Milan Broz <mbroz@xxxxxxxxxx>
[PATCH] Remove BIO_RW_SYNCIO flag from kcopyd
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
[PATCH] dm-kcopyd: Delayed unplug of the queues
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
Re: Fwd: [dm-crypt] [BUG] bad performance and system stalls when using dm-crypt
- From: dave b <db.pub.mail@xxxxxxxxx>
Re: Fwd: [dm-crypt] [BUG] bad performance and system stalls when using dm-crypt
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: Fwd: [dm-crypt] [BUG] bad performance and system stalls when using dm-crypt
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: CFQ and dm-crypt
- From: Milan Broz <mbroz@xxxxxxxxxx>
Re: unmapping luns doesn't work (good)
- From: "Chauhan, Vijay" <Vijay.Chauhan@xxxxxxx>
Re: unmapping luns doesn't work (good)
- From: Rudy Gevaert <Rudy.Gevaert@xxxxxxxx>
[PATCH v2 19/22] dm: use little-endian bit operations
- From: Akinobu Mita <akinobu.mita@xxxxxxxxx>
failure in path between fc switch and storage: info request
- From: Gianluca Cecchi <gianluca.cecchi@xxxxxxxxx>

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