summaryrefslogtreecommitdiff
path: root/drivers/md/dm-mpath.c
AgeCommit message (Collapse)AuthorFilesLines
2005-09-28[PATCH] device-mapper: Fix queue_if_no_path initialisationAlasdair G Kergon1-6/+10
When creating a multipath device, if the queue_if_no_path parameter is specified it gets ignored. While the queue_if_no_path variable is correctly set to 1, the saved_queue_if_no_path gets set to 0. When the device is subsequently made live (resumed), the saved value (0) always overwrites the live value (1) so the option *always* gets turned off. The fix adds a parameter to the queue_if_no_path() function to indicate whether the previous value should be preserved or not - if not, as when the device is being set up, the saved value is set to the new value (1). Signed-Off-By: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-13[PATCH] device-mapper multipath: Fix pg initialisation racesAlasdair G Kergon1-14/+23
Prevent more than one priority group initialisation function from being outstanding at once. Otherwise the completion functions interfere with each other. Also, reloading the table could reference a freed pointer. Only reset queue_io in pg_init_complete if another pg_init isn't required. Skip process_queued_ios if the queue is empty so that we only trigger a pg_init if there's I/O. Signed-off-by: Lars Marowsky-Bree <lmb@suse.de> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-13[PATCH] device-mapper multipath: Avoid possible suspension deadlockAlasdair G Kergon1-12/+13
To avoid deadlock when suspending a multipath device after all its paths have failed, stop queueing any I/O that is about to fail *before* calling freeze_bdev instead of after. Instead of setting a multipath 'suspended' flag which would have to be reset if an error occurs during the process, save the previous queueing state and leave userspace to restore if it wishes. Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-13[PATCH] device-mapper multipath: Flush workqueue when destroyingAlasdair G Kergon1-0/+2
The multipath destructor must flush its workqueue. Otherwise items that reference the destroyed object could remain. From: "goggin, edward" <egoggin@emc.com> Signed-off-by: Lars Marowsky-Bree <lmb@suse.de> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-13[PATCH] device-mapper multipath: Barriers not supportedAlasdair G Kergon1-0/+6
dm multipath will report barriers as not supported with this patch. Signed-off-by: Lars Marowsky-Bree <lmb@suse.de> Signed-off-by: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-09[PATCH] dm: Handle READA requests in dm-mpath.cLars Marowsky-Bree1-0/+3
READA errors failing with EWOULDBLOCK/EAGAIN do not constitute a valid reason for failing the path; this lead to erratic errors on DM multipath devices. This error can be safely propagated upwards without failing the path. Acked-by: Kevin Corry <kevcorry@us.ibm.com> Acked-by: Jens Axboe <axboe@suse.de> Signed-off-by: Lars Marowsky-Bree <lmb@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-06[PATCH] device-mapper multipath: Use private workqueueAlasdair G Kergon1-10/+22
dm-mpath.c needs to use a private workqueue (like other dm targets already do) to avoid interfering with users of the default workqueue. Signed-Off-By: Alasdair G Kergon <agk@redhat.com> Acked-by: Jens Axboe <axboe@suse.de> Signed-off-by: Lars Marowsky-Bree <lmb@suse.de> Signed-off-by: <mikenc@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-17Linux-2.6.12-rc2Linus Torvalds1-0/+1302
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!