On Thu, Feb 14 2019 at 6:21pm -0500,
Nikos Tsironis wrote:
> When provisioning a new data block for a virtual block, either because
> the block was previously unallocated or because we are breaking sharing,
> if the whole block of data is being overwritten the bio that triggered
> the provisioni
When provisioning a new data block for a virtual block, either because
the block was previously unallocated or because we are breaking sharing,
if the whole block of data is being overwritten the bio that triggered
the provisioning is issued immediately, skipping copying or zeroing of
the data bloc
On Thu, Feb 14 2019 at 4:19am -0500,
yangerkun wrote:
> Since 57c36519e4("dm: fix clone_bio() to trigger blk_recount_segments()")
> has been reverted by fa8db494("dm: don't use bio_trim() afterall"), the
> problem that clone bio won't trigger blk_recount_segments will exits
> again. So just clea
When provisioning a new data block for a virtual block, either because
the block was previously unallocated or because we are breaking sharing,
if the whole block of data is being overwritten the bio that triggered
the provisioning is issued immediately, skipping copying or zeroing of
the data bloc
On Thu, Feb 14 2019 at 11:54am -0500,
Mikulas Patocka wrote:
>
>
> On Thu, 14 Feb 2019, Mike Snitzer wrote:
>
> > On Thu, Feb 14 2019 at 10:00am -0500,
> > Mikulas Patocka wrote:
> >
> > > This patch improves performance of dm-linear and dm-striped targets.
> > > Device mapper copies the who
On Thu, 14 Feb 2019, Mike Snitzer wrote:
> On Thu, Feb 14 2019 at 10:00am -0500,
> Mikulas Patocka wrote:
>
> > This patch improves performance of dm-linear and dm-striped targets.
> > Device mapper copies the whole bio and passes it to the lower layer. This
> > copying may be avoided in spec
On Thu, Feb 14 2019 at 10:00am -0500,
Mikulas Patocka wrote:
> This patch improves performance of dm-linear and dm-striped targets.
> Device mapper copies the whole bio and passes it to the lower layer. This
> copying may be avoided in special cases.
>
> This patch changes the logic so that inst
This patch refactors end_io_acct, so that it doesn't take a pointer to
struct dm_io - so that it could be used in the following patch.
Signed-off-by: Mikulas Patocka
---
drivers/md/dm.c | 38 ++
1 file changed, 18 insertions(+), 20 deletions(-)
Index: linu
Hi
Here I'm sending the dm-noclone patches. The patches improve performance
for dm-linear and dm-stripe by avoid cloning the whole bio.
I deliberately decided to not support other targets becase:
* they are more complicated, that means that we need larger noclone
structure and large structure u
This patch refactors start_io_acct, so that it doesn't take a pointer to
struct dm_io - so that it could be used in the following patch.
Signed-off-by: Mikulas Patocka
---
drivers/md/dm.c | 30 --
1 file changed, 12 insertions(+), 18 deletions(-)
Index: linux-2.6/
Move the definition of struct dm_table from dm-table.c to dm-core.h - so,
that it can be used by dm.c.
Signed-off-by: Mikulas Patocka
---
drivers/md/dm-core.h | 45 +
drivers/md/dm-table.c | 44
2 file
This patch improves performance of dm-linear and dm-striped targets.
Device mapper copies the whole bio and passes it to the lower layer. This
copying may be avoided in special cases.
This patch changes the logic so that instead of copying the bio we
allocate a structure dm_noclone (it has only 4
On Wed, 2019-02-13 at 16:55 -0600, Benjamin Marzinski wrote:
> I recently got a bug from a user with a bad property
> blacklist_exceptions line, where multipath tried to use a zram
> device,
> which caused multipathd to crash. This patch set fixes that crash,
> and
> then adds some additional safeg
Since 57c36519e4("dm: fix clone_bio() to trigger blk_recount_segments()")
has been reverted by fa8db494("dm: don't use bio_trim() afterall"), the
problem that clone bio won't trigger blk_recount_segments will exits
again. So just clean the flag in clone_bio.
Fixes: fa8db4948f522("dm: don't use bio
Any comments about the patch?
On 2/14/2019 10:31 AM, Martin K. Petersen wrote:
zhangxiaoxu,
Any progress about the problme?
Should we disable the write same when stack the different LBA disks?
Yes, please.
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listin
On Wed, Feb 13, 2019 at 07:08:40PM +0100, Zdenek Kabelac wrote:
> Dne 13. 02. 19 v 16:01 Bryn M. Reeves napsal(a):
> > On Wed, Feb 13, 2019 at 03:21:52PM +0100, Zdenek Kabelac wrote:
> > > If you have this free space it's surely not a bad thing - but there
> > > are many cases, you can get any free
Can u help me
On Sat, Jan 19, 2019, 12:00 PM wrote:
> Send dm-devel mailing list submissions to
> dm-devel@redhat.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.redhat.com/mailman/listinfo/dm-devel
> or, via email, send a message with subject or b
17 matches
Mail list logo
