s/dm-devel/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
error messages consistent.
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
l_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
Acked-by: Tejun Heo
Cc: Jens Axboe
1d6/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
Acked-by: Vivek Go
ctl+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'i
and read corrupted data)
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 erro
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
>
;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 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/
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 war
[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'
user 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
-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
@@ -
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 pat
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 &a
1f7/0x1f7
> [] 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
gt; ent = ent->next;
ent 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
and request 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/bl
64_start_kernel+0x101/0x110
blk_put_rl() does this:
if (rl->blkg && rl->blkg->blkcg != &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_dest
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 lis
e, I think.)
Naoya'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/
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
ader will
likely get errors again 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 "unsub
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 Nom
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
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
the message is just
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
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
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 outs
ns.
Alasdair G 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
result in setting
wrong device size.
Also, bdget() allocates 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
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: linu
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/
de->i_size is 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
_LOCK is
waiting for completion of table replacement.
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 at http://www.tux.org/lkml/
count = %d (%p)\n",
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'
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
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
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 dev
38 matches
Mail list logo
