/2013-August/msg00084.html
http://www.redhat.com/archives/dm-devel/2013-September/msg00024.html
Signed-off-by: Jun'ichi Nomura
Acked-by: Mike Snitzer
Cc: Jens Axboe
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 2fdb4a4..0e6f765 100644
--- a/include/linux/blkdev.h
+++ b
/2013-August/msg00084.html
http://www.redhat.com/archives/dm-devel/2013-September/msg00024.html
Signed-off-by: Jun'ichi Nomura j-nom...@ce.jp.nec.com
Acked-by: Mike Snitzer snit...@redhat.com
Cc: Jens Axboe ax...@kernel.dk
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 2fdb4a4
stent.
I.e. for the above case, the error message should be
"Request-based dm doesn't support multiple targets yet",
not "Inconsistent table: different target types can't be mixed up".
---
Jun'ichi Nomura, NEC Corporation
diff --git a/drivers/md/dm-table.c b/drivers/md/dm-tabl
multiple targets yet,
not Inconsistent table: different target types can't be mixed up.
---
Jun'ichi Nomura, NEC Corporation
diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index f221812..6e683c8 100644
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -860,14 +860,16
ctl+0x13/0x17 [dm_mod]
[] do_vfs_ioctl+0x3fb/0x441
[] ? file_has_perm+0x8a/0x99
[] sys_ioctl+0x5e/0x82
[] ? trace_hardirqs_on_thunk+0x3a/0x3f
[] system_call_fastpath+0x16/0x1b
Signed-off-by: Jun'ichi Nomura
Acked-by: Vivek Goyal
Acked-by: Tejun Heo
Cc: Jens Axboe
Cc: Alasdair G Kergo
[812010be] ? trace_hardirqs_on_thunk+0x3a/0x3f
[814310d9] system_call_fastpath+0x16/0x1b
Signed-off-by: Jun'ichi Nomura j-nom...@ce.jp.nec.com
Acked-by: Vivek Goyal vgo...@redhat.com
Acked-by: Tejun Heo t...@kernel.org
Cc: Jens Axboe ax...@kernel.dk
Cc: Alasdair G Kergon
? table_clear+0xaa/0xaa [dm_mod]
[] dm_ctl_ioctl+0x13/0x17 [dm_mod]
[] do_vfs_ioctl+0x3fb/0x441
[] ? file_has_perm+0x8a/0x99
[] sys_ioctl+0x5e/0x82
[] ? trace_hardirqs_on_thunk+0x3a/0x3f
[] system_call_fastpath+0x16/0x1b
Signed-off-by: Jun'ichi Nomura
Acked-by: Vivek Goyal
Cc:
[81147aa0] sys_ioctl+0x5e/0x82
[812010be] ? trace_hardirqs_on_thunk+0x3a/0x3f
[814310d9] system_call_fastpath+0x16/0x1b
Signed-off-by: Jun'ichi Nomura j-nom...@ce.jp.nec.com
Acked-by: Vivek Goyal vgo...@redhat.com
Cc: Tejun Heo t...@kernel.org
Cc: Jens Axboe ax
0x1d6/0x236 [dm_mod]
[] ? table_clear+0xaa/0xaa [dm_mod]
[] dm_ctl_ioctl+0x13/0x17 [dm_mod]
[] do_vfs_ioctl+0x3fb/0x441
[] ? file_has_perm+0x8a/0x99
[] sys_ioctl+0x5e/0x82
[] ? trace_hardirqs_on_thunk+0x3a/0x3f
[] system_call_fastpath+0x16/0x1b
Signed-off-by: Jun'ichi Nomura
Cc: Vi
For IO errors come from disk failure, next read will likely fail
again so we don't have to remember it somewhere.
>> Also, if you're going to keep this state in memory, what happens if
>> the inode gets pushed out of memory?
>
> You lose the error, just like you do today wi
On 10/27/12 05:21, Vivek Goyal wrote:
> On Thu, Oct 25, 2012 at 06:41:11PM +0900, Jun'ichi Nomura wrote:
>> [PATCH] dm: stay in blk_queue_bypass until queue becomes initialized
>>
>> With 749fefe677 ("block: lift the initial queue bypass mode on
>&
read will likely succeed reading old data from disk
in case of the memory error.
I'm afraid the read-after-write inconsistency could cause silent data
corruption.
--
Jun'ichi Nomura, NEC Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
read will likely fail
again so we don't have to remember it somewhere.
Also, if you're going to keep this state in memory, what happens if
the inode gets pushed out of memory?
You lose the error, just like you do today with any other IO error.
--
Jun'ichi Nomura, NEC Corporation
] ? trace_hardirqs_on_thunk+0x3a/0x3f
[814310d9] system_call_fastpath+0x16/0x1b
Signed-off-by: Jun'ichi Nomura j-nom...@ce.jp.nec.com
Cc: Vivek Goyal vgo...@redhat.com
Cc: Tejun Heo t...@kernel.org
Cc: Jens Axboe ax...@kernel.dk
Cc: Alasdair G Kergon a...@redhat.com
---
block/blk-cgroup.c |4
-overs
in storage stack and not visible to applications which don't care.)
So it's consistent in some sense.
OTOH, the next read will likely succeed reading old data from disk
in case of the memory error.
I'm afraid the read-after-write inconsistency could cause silent data
corruption.
--
Jun'ichi
On 10/27/12 05:21, Vivek Goyal wrote:
On Thu, Oct 25, 2012 at 06:41:11PM +0900, Jun'ichi Nomura wrote:
[PATCH] dm: stay in blk_queue_bypass until queue becomes initialized
With 749fefe677 (block: lift the initial queue bypass mode on
blk_register_queue() instead of blk_init_allocated_queue
On 10/25/12 18:41, Jun'ichi Nomura wrote:
> With 749fefe677 ("block: lift the initial queue bypass mode on
> blk_register_queue() instead of blk_init_allocated_queue()"),
> add_disk() eventually calls blk_queue_bypass_end().
> This change invokes the following warning
[PATCH] block: move blk_queue_bypass_{start,end} to include/linux/blkdev.h
dm wants to use those functions to control the bypass status of
half-initialized device.
This patch is a preparation for:
[PATCH] dm: stay in blk_queue_bypass until queue becomes initialized
Signed-off-by: Jun'ichi
0m0.442s
sys 0m6.861s
If this additional cost is not negligible, we need a variant of add_disk()
that does not end bypassing.
Signed-off-by: Jun'ichi Nomura
Cc: Vivek Goyal
Cc: Tejun Heo
Cc: Jens Axboe
Cc: Alasdair G Kergon
---
drivers/md/dm.c|4
1 file changed, 4 insertion
of add_disk()
that does not end bypassing.
Signed-off-by: Jun'ichi Nomura j-nom...@ce.jp.nec.com
Cc: Vivek Goyal vgo...@redhat.com
Cc: Tejun Heo t...@kernel.org
Cc: Jens Axboe ax...@kernel.dk
Cc: Alasdair G Kergon a...@redhat.com
---
drivers/md/dm.c|4
1 file changed, 4 insertions
[PATCH] block: move blk_queue_bypass_{start,end} to include/linux/blkdev.h
dm wants to use those functions to control the bypass status of
half-initialized device.
This patch is a preparation for:
[PATCH] dm: stay in blk_queue_bypass until queue becomes initialized
Signed-off-by: Jun'ichi
On 10/25/12 18:41, Jun'ichi Nomura wrote:
With 749fefe677 (block: lift the initial queue bypass mode on
blk_register_queue() instead of blk_init_allocated_queue()),
add_disk() eventually calls blk_queue_bypass_end().
This change invokes the following warning when multipath is used
-off-by: Jun'ichi Nomura
Cc: Vivek Goyal
Cc: Tejun Heo
Cc: Jens Axboe
---
block/blk-cgroup.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index 54f35d1..a31e678 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -333,6
t;> check and original patch which I had acked.
>>
>> Can you please send another patch to change that? It really isn't a
>> related change and I don't wanna mix the two.
>
> Sure. Jun'ichi, would you like to send that cleanup line in a separate patch?
OK
.
Can you please send another patch to change that? It really isn't a
related change and I don't wanna mix the two.
Sure. Jun'ichi, would you like to send that cleanup line in a separate patch?
OK. I will send that patch.
--
Jun'ichi Nomura, NEC Corporation
--
To unsubscribe from this list
-off-by: Jun'ichi Nomura j-nom...@ce.jp.nec.com
Cc: Vivek Goyal vgo...@redhat.com
Cc: Tejun Heo t...@kernel.org
Cc: Jens Axboe ax...@kernel.dk
---
block/blk-cgroup.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index 54f35d1
On 10/17/12 22:47, Vivek Goyal wrote:
> On Wed, Oct 17, 2012 at 09:02:22AM +0900, Jun'ichi Nomura wrote:
>> On 10/17/12 08:20, Tejun Heo wrote:
>>>>>> -if (ent == >root_blkg->q_node)
>>>>>> +if (q->root_blkg && ent == &g
x1f7
> [] x86_64_start_reservations+0xb8/0xbd
> [] x86_64_start_kernel+0x101/0x110
This patch clears q->root_blkg and q->root_rl.blkg when root blkg
is destroyed.
Signed-off-by: Jun'ichi Nomura
Acked-by: Vivek Goyal
Cc: Tejun Heo
Cc: Jens Axboe
---
v3:
Removed a hunk for NULL-c
[81cdb2dd] x86_64_start_reservations+0xb8/0xbd
[81cdb3e3] x86_64_start_kernel+0x101/0x110
This patch clears q-root_blkg and q-root_rl.blkg when root blkg
is destroyed.
Signed-off-by: Jun'ichi Nomura j-nom...@ce.jp.nec.com
Acked-by: Vivek Goyal vgo...@redhat.com
Cc: Tejun Heo t
On 10/17/12 22:47, Vivek Goyal wrote:
On Wed, Oct 17, 2012 at 09:02:22AM +0900, Jun'ichi Nomura wrote:
On 10/17/12 08:20, Tejun Heo wrote:
-if (ent == q-root_blkg-q_node)
+if (q-root_blkg ent == q-root_blkg-q_node)
Can we fix it little differently. Little earlier in the code
blkg_list again.
> if (ent == >root_blkg->q_node)
So ent is not >root_blkg->q_node.
> ent = ent->next;
> if (ent == >blkg_list)
> return NULL;
And we return NULL here.
Ah, yes. You are correct.
We can do without the abo
is q-blkg_list again.
if (ent == q-root_blkg-q_node)
So ent is not q-root_blkg-q_node.
ent = ent-next;
if (ent == q-blkg_list)
return NULL;
And we return NULL here.
Ah, yes. You are correct.
We can do without the above hunk.
--
Jun'ichi Nomura
t list point of view
> root blkg is gone and you can't get to it. (It might still be around for
> some more time due to pending IOs though).
>
> Some minor comments below.
>
>>
>> Signed-off-by: Jun'ichi Nomura
>>
>> diff --git a/block/blk-cgroup.c b/block/b
due to pending IOs though).
Some minor comments below.
Signed-off-by: Jun'ichi Nomura j-nom...@ce.jp.nec.com
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index f3b44a6..5015764 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -285,6 +285,9 @@ static void
110
blk_put_rl() does this:
if (rl->blkg && rl->blkg->blkcg != _root)
blkg_put(rl->blkg);
but if rl is q->root_rl, rl->blkg might be a bogus pointer
because blkcg_deactivate_policy() does not clear q->root_rl.blkg
after blkg_destroy_all().
A
().
Attached patch works for me.
Signed-off-by: Jun'ichi Nomura j-nom...@ce.jp.nec.com
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index f3b44a6..5015764 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -285,6 +285,9 @@ static void blkg_destroy_all(struct request_queue *q
function do something like:
pools->bs = (type == DM_TYPE_BIO_BASED) ?
bioset_create(pool_size, 0) :
bioset_create(pool_size, offsetof(struct
dm_rq_clone_bio_info, clone));
--
Jun'ichi Nomura, NEC Corporation
--
To unsubscribe from this
== DM_TYPE_BIO_BASED) ?
bioset_create(pool_size, 0) :
bioset_create(pool_size, offsetof(struct
dm_rq_clone_bio_info, clone));
--
Jun'ichi Nomura, NEC Corporation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
aoya's patch will keep the failure information and allows the reader
to get I/O error when it reads from broken pagecache.
--
Jun'ichi Nomura, NEC Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
.
--
Jun'ichi Nomura, NEC Corporation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
s = bioset_create(pool_size,
> + offsetof(struct dm_rq_clone_bio_info, orig));
> if (!pools->bs)
> goto free_tio_pool_and_out;
Shouldn't this be offsetof(struct dm_rq_clone_bio_info, clone)?
--
Jun'ichi Nomura, NEC Corporation
--
To unsubscribe from this list:
ain instead of bad data.
Also, ext3/ext4 has an option to panic when an error is detected,
for people who want to avoid corruption on intermittent errors.
--
Jun'ichi Nomura, NEC Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
when an error is detected,
for people who want to avoid corruption on intermittent errors.
--
Jun'ichi Nomura, NEC Corporation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
,
+ offsetof(struct dm_rq_clone_bio_info, orig));
if (!pools-bs)
goto free_tio_pool_and_out;
Shouldn't this be offsetof(struct dm_rq_clone_bio_info, clone)?
--
Jun'ichi Nomura, NEC Corporation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Gary Hade wrote:
> Remove default PCI expansion ROM memory allocation
Thank you Gary for the new patch.
By not allocating resources for expansion ROM,
this patch will eliminate the problem that my patch masked, too:
http://lkml.org/lkml/2007/12/4/284
Regards,
--
Jun'ichi Nomura,
Gary Hade wrote:
Remove default PCI expansion ROM memory allocation
Thank you Gary for the new patch.
By not allocating resources for expansion ROM,
this patch will eliminate the problem that my patch masked, too:
http://lkml.org/lkml/2007/12/4/284
Regards,
--
Jun'ichi Nomura, NEC Corporation
Gary Hade wrote:
> On Tue, Dec 04, 2007 at 06:23:32PM -0500, Jun'ichi Nomura wrote:
>> Kernel always tries to. But it's best effort basis, IMO.
>> (Maybe your patch is going to fix that?)
>
> If you are seeing the allocation failures both with and
> without m
Gary Hade wrote:
On Tue, Dec 04, 2007 at 06:23:32PM -0500, Jun'ichi Nomura wrote:
Kernel always tries to. But it's best effort basis, IMO.
(Maybe your patch is going to fix that?)
If you are seeing the allocation failures both with and
without my original patch I doubt that an improved
Hi Gary,
Gary Hade wrote:
> On Tue, Dec 04, 2007 at 02:35:48PM -0500, Jun'ichi Nomura wrote:
>> On a system with PCI-to-PCI bridges, following errors are observed:
>>
>> PCI: Failed to allocate mem resource #8:[EMAIL PROTECTED] for :02:00.0
>> PCI: Failed to allo
confusing.
This patch omits the error message if the resource is an expansion
ROM or a bridge.
Thanks,
--
Jun'ichi Nomura, NEC Corporation of America
Signed-off-by: Jun'ichi Nomura <[EMAIL PROTECTED]>
--- linux-2.6.24-rc3/drivers/pci/setup-res.c.orig 2007-12-04
00:24:11.0
confusing.
This patch omits the error message if the resource is an expansion
ROM or a bridge.
Thanks,
--
Jun'ichi Nomura, NEC Corporation of America
Signed-off-by: Jun'ichi Nomura [EMAIL PROTECTED]
--- linux-2.6.24-rc3/drivers/pci/setup-res.c.orig 2007-12-04
00:24:11.0 -0500
Hi Gary,
Gary Hade wrote:
On Tue, Dec 04, 2007 at 02:35:48PM -0500, Jun'ichi Nomura wrote:
On a system with PCI-to-PCI bridges, following errors are observed:
PCI: Failed to allocate mem resource #8:[EMAIL PROTECTED] for :02:00.0
PCI: Failed to allocate mem resource #6:[EMAIL PROTECTED
count=1 &
echo "Wait til dd push some I/O"
sleep 5
dmsetup resume ${MAP}
------
Signed-off-by: Jun'ichi Nomura <[EMAIL PROTECTED]>
---
dm-ioctl.c | 10 +++---
dm-table.c |3 +++
dm.c | 24 +
push some I/O
sleep 5
dmsetup resume ${MAP}
--
Signed-off-by: Jun'ichi Nomura [EMAIL PROTECTED]
---
dm-ioctl.c | 10 +++---
dm-table.c |3 +++
dm.c | 24 ++--
3 files changed, 24
Alasdair,
Jun'ichi Nomura wrote:
> So as far as I understand, the point is:
> 1. it's preferable to resize inode after the resume, if possible
Attached is a modified version of the (2/3) patch.
- The logic is basically the same as before.
- Moved the set-size function outside of the
Kergon wrote:
> On Thu, Oct 25, 2007 at 10:18:02AM -0400, Jun'ichi Nomura wrote:
>> There is no guarantee that the I/O flowing through the device again.
>> The table might need be replaced again, but to do that, the resume
>> should have been completed to l
new bdev inode if there isn't.
But dm wants to access bdev inode only when it exists in memory.
So something like bdlookup() will fit for the purpose, IMO.
Thanks,
--
Jun'ichi Nomura, NEC Corporation of America
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
bdlookup() will fit for the purpose, IMO.
Thanks,
--
Jun'ichi Nomura, NEC Corporation of America
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
Kergon wrote:
On Thu, Oct 25, 2007 at 10:18:02AM -0400, Jun'ichi Nomura wrote:
There is no guarantee that the I/O flowing through the device again.
The table might need be replaced again, but to do that, the resume
should have been completed to let the userspace know it.
Then the first
Alasdair,
Jun'ichi Nomura wrote:
So as far as I understand, the point is:
1. it's preferable to resize inode after the resume, if possible
Attached is a modified version of the (2/3) patch.
- The logic is basically the same as before.
- Moved the set-size function outside of the table
This patch removes the check for whether the loaded table
is going to change the device size and allows resizing of
the dm device suspended with 'noflush'.
Signed-off-by: Jun'ichi Nomura <[EMAIL PROTECTED]>
---
dm.c |5 -
1 file changed, 5 deletions(-)
Index: linux-2.6.23.work/d
or forever.
Signed-off-by: Jun'ichi Nomura <[EMAIL PROTECTED]>
---
fs/block_dev.c| 27 +++
include/linux/fs.h|4 +++-
include/linux/genhd.h |6 ++
3 files changed, 36 insertions(+), 1 deletion(-)
Index: linux-2.6.23.work/fs/block
s set via bd_set_size() and bd_set_size()
is protected by bd_mutex.
So I think bd_mutex is the lock we should use.
Signed-off-by: Jun'ichi Nomura <[EMAIL PROTECTED]>
---
dm.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
Index: linux-2.6.23.work/
,
--
Jun'ichi Nomura, NEC Corporation of America
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
,
--
Jun'ichi Nomura, NEC Corporation of America
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
or forever.
Signed-off-by: Jun'ichi Nomura [EMAIL PROTECTED]
---
fs/block_dev.c| 27 +++
include/linux/fs.h|4 +++-
include/linux/genhd.h |6 ++
3 files changed, 36 insertions(+), 1 deletion(-)
Index: linux-2.6.23.work/fs/block_dev.c
() and bd_set_size()
is protected by bd_mutex.
So I think bd_mutex is the lock we should use.
Signed-off-by: Jun'ichi Nomura [EMAIL PROTECTED]
---
dm.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
Index: linux-2.6.23.work/drivers/md/dm.c
This patch removes the check for whether the loaded table
is going to change the device size and allows resizing of
the dm device suspended with 'noflush'.
Signed-off-by: Jun'ichi Nomura [EMAIL PROTECTED]
---
dm.c |5 -
1 file changed, 5 deletions(-)
Index: linux-2.6.23.work/drivers
d (%p)\n",
atomic_read(>bdev.bd_mount_sem.count),
>bdev);
Without the patch, I saw something like:
Incorrect semaphore count = 17 (f2ab91c0)
With the patch, the message didn't appear.
Signed-off-by: Jun'ichi Nomura <[EMAIL PROTECTED]>
,
atomic_read(ei-bdev.bd_mount_sem.count),
ei-bdev);
Without the patch, I saw something like:
Incorrect semaphore count = 17 (f2ab91c0)
With the patch, the message didn't appear.
Signed-off-by: Jun'ichi Nomura [EMAIL PROTECTED]
diff --git a/drivers
Patrick McHardy wrote:
> Jun'ichi Nomura wrote:
>> Are you using other dm modules such as dm-multipath, dm-mirror
>> or dm-snapshot?
>> If so, can you take the output of 'dmsetup table' and 'dmsetup ls'?
>
> No other modules.
>
>> Do you have a reliable way t
Hi,
Patrick McHardy wrote:
> Alasdair G Kergon wrote:
>> From: "Jun'ichi Nomura" <[EMAIL PROTECTED]>
>>
>> bio_alloc_bioset() will return NULL if 'num_vecs' is too large.
>> Use bio_get_nr_vecs() to get estimation of maximum number.
>>
>
Hi,
Patrick McHardy wrote:
Alasdair G Kergon wrote:
From: Jun'ichi Nomura [EMAIL PROTECTED]
bio_alloc_bioset() will return NULL if 'num_vecs' is too large.
Use bio_get_nr_vecs() to get estimation of maximum number.
Signed-off-by: Jun'ichi Nomura [EMAIL PROTECTED]
Signed-off-by: Alasdair G
Patrick McHardy wrote:
Jun'ichi Nomura wrote:
Are you using other dm modules such as dm-multipath, dm-mirror
or dm-snapshot?
If so, can you take the output of 'dmsetup table' and 'dmsetup ls'?
No other modules.
Do you have a reliable way to reproduce the oops which I can try?
/etc
to do __set_size() and waits forever.
Signed-off-by: Jun'ichi Nomura <[EMAIL PROTECTED]>
---
'noflush suspend' is a new device-mapper feature introduced in
early 2.6.20. So I hope the fix being included before 2.6.20 is
released.
Example of reproducer:
1. Create a multipath device by dmsetup
__set_size() and waits forever.
Signed-off-by: Jun'ichi Nomura [EMAIL PROTECTED]
---
'noflush suspend' is a new device-mapper feature introduced in
early 2.6.20. So I hope the fix being included before 2.6.20 is
released.
Example of reproducer:
1. Create a multipath device by dmsetup
2. Fail all paths
76 matches
Mail list logo
