On Tue, Dec 22, 2020 at 06:24:09PM +0100, Hannes Reinecke wrote:
> However, lookup_bdev() now always recurses into the filesystem, causing
> multipath to stall in an all-paths-down scenario.
I have not read the background about whatever the new problem is - I'm
jumping in cold seeing this
On Tue, Dec 12, 2017 at 07:45:56AM -0700, Keith Busch wrote:
> Ah, this device's makers call the "stripe" size what should be called
> "chunk".
If this target is to go anywhere, let's try to define it as 'undoing'
the existing dm-stripe target using primary terminology, field names
etc. as close
On Tue, Dec 12, 2017 at 07:45:56AM -0700, Keith Busch wrote:
> Ah, this device's makers call the "stripe" size what should be called
> "chunk".
If this target is to go anywhere, let's try to define it as 'undoing'
the existing dm-stripe target using primary terminology, field names
etc. as close
On Fri, Nov 24, 2017 at 08:29:42AM +, Reshetova, Elena wrote:
> By looking at the code, I don't see where the change in the reference counting
> could have caused this.
The cause was the bug I identified in patch 3, not this patch.
The regression is easily hit - tables that reference the
On Fri, Nov 24, 2017 at 08:29:42AM +, Reshetova, Elena wrote:
> By looking at the code, I don't see where the change in the reference counting
> could have caused this.
The cause was the bug I identified in patch 3, not this patch.
The regression is easily hit - tables that reference the
On Fri, Oct 20, 2017 at 10:37:38AM +0300, Elena Reshetova wrote:
> } else if (dd->dm_dev->mode != (mode | dd->dm_dev->mode)) {
> r = upgrade_mode(dd, mode, t->md);
> if (r)
> return r;
> + refcount_inc(>count);
> }
Missing
On Fri, Oct 20, 2017 at 10:37:38AM +0300, Elena Reshetova wrote:
> } else if (dd->dm_dev->mode != (mode | dd->dm_dev->mode)) {
> r = upgrade_mode(dd, mode, t->md);
> if (r)
> return r;
> + refcount_inc(>count);
> }
Missing
Some more thoughts with your example, dmsetup might look like:
# dmsetup create --bootformat "lroot:uuid,rw,0 2097152 linear 8:2 0, \
2097152 2097152 linear 8:3 0, 4194304 2097152 linear 8:4 0"
- also supporting creating multiple devices if the semi-colon is used
- colon to separate name from
Some more thoughts with your example, dmsetup might look like:
# dmsetup create --bootformat "lroot:uuid,rw,0 2097152 linear 8:2 0, \
2097152 2097152 linear 8:3 0, 4194304 2097152 linear 8:4 0"
- also supporting creating multiple devices if the semi-colon is used
- colon to separate name from
On Thu, May 04, 2017 at 01:18:41PM +0200, Enric Balletbo Serra wrote:
> I'm wondering if a command line like this would be acceptable.
1) Make sure the implementation continues to support backslash quoting
so that any characters you introduce with special meanings (comma,
semi-colon, double-quote
On Thu, May 04, 2017 at 01:18:41PM +0200, Enric Balletbo Serra wrote:
> I'm wondering if a command line like this would be acceptable.
1) Make sure the implementation continues to support backslash quoting
so that any characters you introduce with special meanings (comma,
semi-colon, double-quote
On Wed, Oct 05, 2016 at 10:06:41AM -0700, Andy Grover wrote:
> My project *would* like this added sooner, so I'll work on a revised
> patchset that uses netlink instead of uevents, and will also work on a
> revision to uevents.txt that talks about KOBJ_CHANGE and when it should
> and should
On Wed, Oct 05, 2016 at 10:06:41AM -0700, Andy Grover wrote:
> My project *would* like this added sooner, so I'll work on a revised
> patchset that uses netlink instead of uevents, and will also work on a
> revision to uevents.txt that talks about KOBJ_CHANGE and when it should
> and should
On Tue, Oct 04, 2016 at 04:39:28PM -0700, Andy Grover wrote:
> devicemapper is using uevents for:
> a. dm-verity detected corruption
> b. dm-multipath: path failed or reinstated
> c. dm device renamed
> d. there's also some use in md and bcache.
>
> devicemapper uses DM_EVENT ioctl (yuck) for:
>
On Tue, Oct 04, 2016 at 04:39:28PM -0700, Andy Grover wrote:
> devicemapper is using uevents for:
> a. dm-verity detected corruption
> b. dm-multipath: path failed or reinstated
> c. dm device renamed
> d. there's also some use in md and bcache.
>
> devicemapper uses DM_EVENT ioctl (yuck) for:
>
On Mon, Apr 11, 2016 at 09:45:01PM +0530, Sudip Mukherjee wrote:
> L stands for "Mailing list that is relevant to this area", and this is a
> mailing list. :)
Your proposed patch isn't changing the L entry, so this is of no relevance.
Alasdair
On Mon, Apr 11, 2016 at 09:45:01PM +0530, Sudip Mukherjee wrote:
> L stands for "Mailing list that is relevant to this area", and this is a
> mailing list. :)
Your proposed patch isn't changing the L entry, so this is of no relevance.
Alasdair
On Mon, Apr 11, 2016 at 08:50:39PM +0530, Sudip Mukherjee wrote:
> The entry of dm-de...@redhat.com was duplicated and the duplicate entry
> was marked as a Maintainer but it appears from the email address that it
> is a List. So remove the entry of M and only keep the L entry.
M and L are not
On Mon, Apr 11, 2016 at 08:50:39PM +0530, Sudip Mukherjee wrote:
> The entry of dm-de...@redhat.com was duplicated and the duplicate entry
> was marked as a Maintainer but it appears from the email address that it
> is a List. So remove the entry of M and only keep the L entry.
M and L are not
On Sat, Feb 20, 2016 at 10:13:49AM -0800, Kees Cook wrote:
> This is a resurrection of a patch series from a few years back, first
> brought to the dm maintainers in 2010. It creates a way to define dm
> devices on the kernel command line for systems that do not use an
> initramfs, or otherwise
On Sat, Feb 20, 2016 at 10:13:49AM -0800, Kees Cook wrote:
> This is a resurrection of a patch series from a few years back, first
> brought to the dm maintainers in 2010. It creates a way to define dm
> devices on the kernel command line for systems that do not use an
> initramfs, or otherwise
On Thu, Jan 28, 2016 at 01:50:19PM +, Andy Whitcroft wrote:
> However this also removed the possibility of a dm target having target
> specific ioctls. Currently this is not used by any in-tree targets but
> was utilised by the flashcache out-of-tree module.
What data is being passed in and
On Thu, Jan 28, 2016 at 01:50:19PM +, Andy Whitcroft wrote:
> However this also removed the possibility of a dm target having target
> specific ioctls. Currently this is not used by any in-tree targets but
> was utilised by the flashcache out-of-tree module.
What data is being passed in and
On Wed, Dec 02, 2015 at 08:46:54PM +0800, Baolin Wang wrote:
> These are the benchmarks for request based dm-crypt. Please check it.
Now please put request-based dm-crypt completely to one side and focus
just on the existing bio-based code. Why is it slower and what can be
adjusted to improve
On Wed, Dec 02, 2015 at 08:46:54PM +0800, Baolin Wang wrote:
> These are the benchmarks for request based dm-crypt. Please check it.
Now please put request-based dm-crypt completely to one side and focus
just on the existing bio-based code. Why is it slower and what can be
adjusted to improve
On Wed, May 27, 2015 at 04:42:44PM -0700, Ming Lin wrote:
> Here are fio results of XFS on a DM stripped target with 2 SSDs + 1 HDD.
> Does it make sense?
To stripe across devices with different characteristics?
Some suggestions.
Prepare 3 kernels.
O - Old kernel.
M - Old kernel with
On Wed, May 27, 2015 at 04:42:44PM -0700, Ming Lin wrote:
Here are fio results of XFS on a DM stripped target with 2 SSDs + 1 HDD.
Does it make sense?
To stripe across devices with different characteristics?
Some suggestions.
Prepare 3 kernels.
O - Old kernel.
M - Old kernel with
On Wed, May 27, 2015 at 09:06:40AM +1000, Neil Brown wrote:
> Because we don't know what the "right" size is. And the "right" size can
> change when array reconfiguration happens.
In certain configurations today, device-mapper does report back a sensible
maximum bio size smaller than would
On Tue, May 26, 2015 at 08:02:08AM -0700, Ming Lin wrote:
> Now bio_add_page() can build lager bios.
> And blk_queue_split() can split the bios in ->make_request() if needed.
But why not try to make the bio the right size in the first place so you
don't have to incur the performance impact of
On Wed, May 27, 2015 at 09:06:40AM +1000, Neil Brown wrote:
Because we don't know what the right size is. And the right size can
change when array reconfiguration happens.
In certain configurations today, device-mapper does report back a sensible
maximum bio size smaller than would otherwise
On Tue, May 26, 2015 at 08:02:08AM -0700, Ming Lin wrote:
Now bio_add_page() can build lager bios.
And blk_queue_split() can split the bios in -make_request() if needed.
But why not try to make the bio the right size in the first place so you
don't have to incur the performance impact of
On Fri, May 01, 2015 at 12:37:07AM -0400, Abelardo Ricart III wrote:
> # first bad commit: [cf2f1abfbd0dba701f7f16ef619e4d2485de3366] dm crypt: don't
> allocate pages for a partial request
That's not a particularly good commit to identify.
If you didn't already, can you confirm whether or not
On Fri, May 01, 2015 at 12:37:07AM -0400, Abelardo Ricart III wrote:
# first bad commit: [cf2f1abfbd0dba701f7f16ef619e4d2485de3366] dm crypt: don't
allocate pages for a partial request
That's not a particularly good commit to identify.
If you didn't already, can you confirm whether or not the
On Mon, Apr 27, 2015 at 11:48:34PM -0700, Ming Lin wrote:
> As generic_make_request() is now able to handle arbitrarily sized bios,
> it's no longer necessary for each individual block driver to define its
> own ->merge_bvec_fn() callback. Remove every invocation completely.
merge_bvec_fn is also
On Mon, Apr 27, 2015 at 11:48:34PM -0700, Ming Lin wrote:
As generic_make_request() is now able to handle arbitrarily sized bios,
it's no longer necessary for each individual block driver to define its
own -merge_bvec_fn() callback. Remove every invocation completely.
merge_bvec_fn is also
On Sun, Apr 05, 2015 at 07:20:19PM +0200, Pali Rohár wrote:
> This patch adds dm message commands and option strings to optionally wipe key
> from dm-crypt device before entering suspend or hibernate state.
Try to avoid 0/1 - use descriptive options instead.
E.g. key wipe_on_hibernation / key
On Sun, Apr 05, 2015 at 07:20:19PM +0200, Pali Rohár wrote:
This patch adds dm message commands and option strings to optionally wipe key
from dm-crypt device before entering suspend or hibernate state.
Try to avoid 0/1 - use descriptive options instead.
E.g. key wipe_on_hibernation / key
On Tue, Feb 17, 2015 at 10:08:56AM +0100, Arnd Bergmann wrote:
> The normal way to do this in kernel headers is to use linux/types.h
> but change the data structures to use __u64 instead of uint64_t
> to avoid the build error.
That's what happened to dm-ioctl.h.
(Or someone could adjust
On Tue, Feb 17, 2015 at 10:08:56AM +0100, Arnd Bergmann wrote:
The normal way to do this in kernel headers is to use linux/types.h
but change the data structures to use __u64 instead of uint64_t
to avoid the build error.
That's what happened to dm-ioctl.h.
(Or someone could adjust
On Tue, Jan 20, 2015 at 06:36:10AM -0500, nick wrote:
> Unless we use a union or something similar there seems to be no easy
> way without rewriting a lot of an already function driver file.
The comment does not restrict itself to 'easy ways'.
Alasdair
--
To unsubscribe from this list: send
On Mon, Jan 19, 2015 at 10:16:21PM -0500, Nicholas Krause wrote:
> Removes the no longer needed fix me comment questioning if we need to remove
> the structure pointer,rh as defined as a structure of type dsm_region_hash
> from the definition of the structure, dm_region. Furthermore this pointer
On Tue, Jan 20, 2015 at 06:36:10AM -0500, nick wrote:
Unless we use a union or something similar there seems to be no easy
way without rewriting a lot of an already function driver file.
The comment does not restrict itself to 'easy ways'.
Alasdair
--
To unsubscribe from this list: send the
On Mon, Jan 19, 2015 at 10:16:21PM -0500, Nicholas Krause wrote:
Removes the no longer needed fix me comment questioning if we need to remove
the structure pointer,rh as defined as a structure of type dsm_region_hash
from the definition of the structure, dm_region. Furthermore this pointer is
On Wed, Jul 23, 2014 at 08:16:58AM -0400, Mikulas Patocka wrote:
> So, it means that you do not use device mapper at all. So, why are you
> trying to change memory allocation in device mapper?
So the *test* they run is asking device-mapper to briefly reserve a 64KB
buffer when there is no data
On Wed, Jul 23, 2014 at 08:16:58AM -0400, Mikulas Patocka wrote:
So, it means that you do not use device mapper at all. So, why are you
trying to change memory allocation in device mapper?
So the *test* they run is asking device-mapper to briefly reserve a 64KB
buffer when there is no data to
On Tue, Jul 22, 2014 at 02:23:52AM +0100, Alasdair G Kergon wrote:
> Unanswered. Let's ask the same question in a different way:
A quick search for 'vold' returns:
https://android.googlesource.com/platform/system/vold/
and the code there requests a fixed 64K allocation to hold the na
>>> On 2014/7/9 6:39, Mikulas Patocka wrote:
>> Which ioctl with more than 16kB
>> arguments do you use?
Unanswered. Let's ask the same question in a different way:
Please supply the output of these three commands on the real-world system on
which you believe that that particular allocation is
On 2014/7/9 6:39, Mikulas Patocka wrote:
Which ioctl with more than 16kB
arguments do you use?
Unanswered. Let's ask the same question in a different way:
Please supply the output of these three commands on the real-world system on
which you believe that that particular allocation is
On Tue, Jul 22, 2014 at 02:23:52AM +0100, Alasdair G Kergon wrote:
Unanswered. Let's ask the same question in a different way:
A quick search for 'vold' returns:
https://android.googlesource.com/platform/system/vold/
and the code there requests a fixed 64K allocation to hold the names
On Sat, Dec 28, 2013 at 12:57:25PM +, Alasdair G Kergon wrote:
> To use this compression target above dm-thin (likely to prefer larger
> block sizes), for example, could the block sizes be adapatable /
> configurable?
So a key feature of the underlying thin provisioning needs to be
I've not looked at this in any depth, but here are some first
impressions:
On Fri, Dec 27, 2013 at 02:24:21PM +0800, Shaohua Li wrote:
> This is a simple DM target supporting compression for SSD only.
Presumably there'll be other disk layouts and other types of compression
in future, so if you
I've not looked at this in any depth, but here are some first
impressions:
On Fri, Dec 27, 2013 at 02:24:21PM +0800, Shaohua Li wrote:
This is a simple DM target supporting compression for SSD only.
Presumably there'll be other disk layouts and other types of compression
in future, so if you
On Sat, Dec 28, 2013 at 12:57:25PM +, Alasdair G Kergon wrote:
To use this compression target above dm-thin (likely to prefer larger
block sizes), for example, could the block sizes be adapatable /
configurable?
So a key feature of the underlying thin provisioning needs to be
efficient
On Wed, Oct 30, 2013 at 10:18:44AM -0700, Greg KH wrote:
> The "module unload" issue is rare, thankfully, but yes, this type of
> function will be showing up in 3.13-rc1 through the btrfs tree as it
> needs that functionality, so feel free to use it to resolve this issue
> if you need it.
On Wed, Oct 30, 2013 at 10:18:44AM -0700, Greg KH wrote:
The module unload issue is rare, thankfully, but yes, this type of
function will be showing up in 3.13-rc1 through the btrfs tree as it
needs that functionality, so feel free to use it to resolve this issue
if you need it.
Excellent!
On Fri, Aug 30, 2013 at 09:33:29PM +0900, Akira Hayakawa wrote:
> I have three candidates on my mind.
> I am thinking of removing the dm- prefix as bcache and enhanceio do.
Yes, that's fine for the general way of referring to this.
(Within the codebase, the filename and module name would still
On Fri, Aug 30, 2013 at 09:33:29PM +0900, Akira Hayakawa wrote:
I have three candidates on my mind.
I am thinking of removing the dm- prefix as bcache and enhanceio do.
Yes, that's fine for the general way of referring to this.
(Within the codebase, the filename and module name would still
On Wed, Aug 28, 2013 at 07:05:55PM -0700, Greg KH wrote:
> For staging drivers, I need a TODO file that lists
> what needs to be done to the code to get it into a mergable state for
> the "real" part of the kernel,
Two simple requirements before putting your proof-of-concept into staging
if you
On Wed, Aug 28, 2013 at 07:05:55PM -0700, Greg KH wrote:
For staging drivers, I need a TODO file that lists
what needs to be done to the code to get it into a mergable state for
the real part of the kernel,
Two simple requirements before putting your proof-of-concept into staging
if you want
On Fri, Aug 16, 2013 at 03:55:21PM -0700, Frank Mayhar wrote:
> This patch fixes that by changing the hardcoded MIN_IOS (and certain
> other) #defines in dm-crypt, dm-io, dm-mpath, dm-snap and dm itself to
> sysctl-modifiable values. This lets us change the size of these pools
> on the fly, we
On Fri, Aug 16, 2013 at 03:55:21PM -0700, Frank Mayhar wrote:
This patch fixes that by changing the hardcoded MIN_IOS (and certain
other) #defines in dm-crypt, dm-io, dm-mpath, dm-snap and dm itself to
sysctl-modifiable values. This lets us change the size of these pools
on the fly, we can
On Fri, Aug 16, 2013 at 01:31:18AM -0700, Guenter Roeck wrote:
> Is this patch going anyhere ? The problem breaks the sparc32:allmodconfig
> build,
> so it would be useful to get it fixed.
We're pulling together a batch of patches today, including this one.
Alasdair
--
To unsubscribe from this
On Fri, Aug 16, 2013 at 01:31:18AM -0700, Guenter Roeck wrote:
Is this patch going anyhere ? The problem breaks the sparc32:allmodconfig
build,
so it would be useful to get it fixed.
We're pulling together a batch of patches today, including this one.
Alasdair
--
To unsubscribe from this
On Mon, Aug 12, 2013 at 04:52:34AM -0700, Christoph Hellwig wrote:
> lvm is mostly about the Linux specific formats. If you want to create
> a separate userspace consumer for device mapper that's probably also
> fine, but if you need support for complex layours device mapper is the
> way to go,
On Mon, Aug 12, 2013 at 04:52:34AM -0700, Christoph Hellwig wrote:
lvm is mostly about the Linux specific formats. If you want to create
a separate userspace consumer for device mapper that's probably also
fine, but if you need support for complex layours device mapper is the
way to go, and
On Thu, Jul 11, 2013 at 04:20:40PM +1000, Stephen Rothwell wrote:
> Alistair, is there some reason that you cannot maintain some relatively
> stable git tree for me to fetch (instead of the quilt series).
Well Mike Snitzer is becoming a joint maintainer and this also requires
changes to the
On Thu, Jul 11, 2013 at 04:20:40PM +1000, Stephen Rothwell wrote:
Alistair, is there some reason that you cannot maintain some relatively
stable git tree for me to fetch (instead of the quilt series).
Well Mike Snitzer is becoming a joint maintainer and this also requires
changes to the
On Thu, Jul 11, 2013 at 10:31:16AM +1000, Stephen Rothwell wrote:
> You have
> just invalidated your testing
On the contrary, it is part of my testing.
> Your whole series was already
> based after v3.10 (i.e. released or rebased after the merge window
> opened), so why move it again?
I
On Thu, Jul 11, 2013 at 10:31:16AM +1000, Stephen Rothwell wrote:
> Why have you just rebased the device-mapper series
I was confirming there weren't any unexpected conflicts or other issues to
deal with from a point after the block tree went in before generating
the pull request.
Alasdair
--
as a device-mapper maintainer.
A few more clean-ups and fixes.
Alasdair G Kergon (2):
dm flakey: correct ctr alloc failure mesg
dm: update maintainers
Hannes Reinecke (1):
dm mpath: fix ioctl deadlock when
as a device-mapper maintainer.
A few more clean-ups and fixes.
Alasdair G Kergon (2):
dm flakey: correct ctr alloc failure mesg
dm: update maintainers
Hannes Reinecke (1):
dm mpath: fix ioctl deadlock when
On Thu, Jul 11, 2013 at 10:31:16AM +1000, Stephen Rothwell wrote:
Why have you just rebased the device-mapper series
I was confirming there weren't any unexpected conflicts or other issues to
deal with from a point after the block tree went in before generating
the pull request.
Alasdair
--
To
On Thu, Jul 11, 2013 at 10:31:16AM +1000, Stephen Rothwell wrote:
You have
just invalidated your testing
On the contrary, it is part of my testing.
Your whole series was already
based after v3.10 (i.e. released or rebased after the merge window
opened), so why move it again?
I usually
On Mon, Jul 08, 2013 at 10:21:43AM -0700, Joe Perches wrote:
> I think this Q entry isn't as useful as it could be
> because it doesn't show the status of any patch.
When kernel.org patchwork was unavailable for many months we migrated
over to a private instance - and we still haven't moved
On Tue, Jul 02, 2013 at 05:01:47PM +0200, Yann Droneaud wrote:
> This patch changes type of dm-de...@redhat.com
> The output of ./scripts/get_maintainer.pl is
> modified to report dm-de...@redhat.com as a list:
> DEVICE-MAPPER (LVM)
> M: Alasdair Kergon
> -M: dm-de...@redhat.com
> L:
On Tue, Jul 02, 2013 at 05:01:47PM +0200, Yann Droneaud wrote:
This patch changes type of dm-de...@redhat.com
The output of ./scripts/get_maintainer.pl is
modified to report dm-de...@redhat.com as a list:
DEVICE-MAPPER (LVM)
M: Alasdair Kergon a...@redhat.com
-M: dm-de...@redhat.com
On Mon, Jul 08, 2013 at 10:21:43AM -0700, Joe Perches wrote:
I think this Q entry isn't as useful as it could be
because it doesn't show the status of any patch.
When kernel.org patchwork was unavailable for many months we migrated
over to a private instance - and we still haven't moved back!
On Thu, Jun 20, 2013 at 06:12:07PM -0700, Geremy Condra wrote:
> Assuming nobody currently using DM_UEVENT minds it doesn't cause any
> problems for me. Any current users object?
DM_UEVENT toggles uevents on or off across the whole of device-mapper.
If there is no particular need for verity
On Thu, Jun 20, 2013 at 02:21:00PM -0700, Geremy Condra wrote:
> With this change and config option, dm-verity errors
> will cause uevents to be sent to userspace, notifying
> it that an error has occurred and potentially
> triggering recovery actions.
> +config DM_VERITY_ERROR_NOTIFY
> +
On Thu, Jun 20, 2013 at 02:21:00PM -0700, Geremy Condra wrote:
With this change and config option, dm-verity errors
will cause uevents to be sent to userspace, notifying
it that an error has occurred and potentially
triggering recovery actions.
+config DM_VERITY_ERROR_NOTIFY
+ tristate
On Thu, Jun 20, 2013 at 06:12:07PM -0700, Geremy Condra wrote:
Assuming nobody currently using DM_UEVENT minds it doesn't cause any
problems for me. Any current users object?
DM_UEVENT toggles uevents on or off across the whole of device-mapper.
If there is no particular need for verity *not*
devices.
Alasdair G Kergon (1):
dm thin: fix metadata dev resize detection
drivers/md/dm-thin.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-k
devices.
Alasdair G Kergon (1):
dm thin: fix metadata dev resize detection
drivers/md/dm-thin.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Fri, May 10, 2013 at 11:20:29AM +0100, Alasdair G Kergon wrote:
> Please pull from:
> git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm
> tags/dm-3.10-changes
And the kbuild test robot just spotted that I lost a line from one of
the patches which meant the thin
thin
provisioning target to be extended easily; allow WRITE SAME on
multipath devices; an assortment of little fixes and clean-ups.
Alasdair G Kergon (3):
dm: document iterate_devices
dm cache policy: fix description
thin
provisioning target to be extended easily; allow WRITE SAME on
multipath devices; an assortment of little fixes and clean-ups.
Alasdair G Kergon (3):
dm: document iterate_devices
dm cache policy: fix description
On Fri, May 10, 2013 at 11:20:29AM +0100, Alasdair G Kergon wrote:
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm
tags/dm-3.10-changes
And the kbuild test robot just spotted that I lost a line from one of
the patches which meant the thin threshold notification
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm tags/dm-3.9-fixes-2
to get the following device-mapper fixes for 3.9.
Thanks,
Alasdair
A pair of patches to fix the writethrough mode of the
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm tags/dm-3.9-fixes-2
to get the following device-mapper fixes for 3.9.
Thanks,
Alasdair
A pair of patches to fix the writethrough mode of the
[Adding dm-crypt + linux-kernel]
On Mon, Mar 25, 2013 at 11:47:22PM -0400, Mikulas Patocka wrote:
> I performed some dm-crypt performance tests as Mike suggested.
>
> It turns out that unbound workqueue performance has improved somewhere
> between kernel 3.2 (when I made the dm-crypt patches)
[Adding dm-crypt + linux-kernel]
On Mon, Mar 25, 2013 at 11:47:22PM -0400, Mikulas Patocka wrote:
I performed some dm-crypt performance tests as Mike suggested.
It turns out that unbound workqueue performance has improved somewhere
between kernel 3.2 (when I made the dm-crypt patches) and
On Fri, Mar 22, 2013 at 10:15:49PM -0700, Darrick J. Wong wrote:
> Interesting ... if I set up this:
> # echo "0 67108864 linear /dev/sda 0" | dmsetup create origin
> And then repeat the test, but using /dev/mapper/origin as the origin instead
> of /dev/sda, the problem goes away.
So that looks
On Fri, Mar 22, 2013 at 10:15:49PM -0700, Darrick J. Wong wrote:
Interesting ... if I set up this:
# echo 0 67108864 linear /dev/sda 0 | dmsetup create origin
And then repeat the test, but using /dev/mapper/origin as the origin instead
of /dev/sda, the problem goes away.
So that looks like
On Fri, Mar 22, 2013 at 11:27:16PM -0400, Mike Snitzer wrote:
> So the big difference is the thinp-test-suite uses intermediate linear
> DM layers above the slower sd device (spindle/data) -- whereas in your
> setup the origin device is direct to sd (8:0).
I would think the difference is because
On Fri, Mar 22, 2013 at 01:11:51PM -0700, Darrick J. Wong wrote:
> The new writethrough strategy for dm-cache issues a bio to the origin device,
> remaps the bio to the cache device, and issues the bio to the cache device.
> However, the block layer modifies bi_sector and bi_size, so we need to
>
On Fri, Mar 22, 2013 at 01:11:51PM -0700, Darrick J. Wong wrote:
The new writethrough strategy for dm-cache issues a bio to the origin device,
remaps the bio to the cache device, and issues the bio to the cache device.
However, the block layer modifies bi_sector and bi_size, so we need to
On Fri, Mar 22, 2013 at 11:27:16PM -0400, Mike Snitzer wrote:
So the big difference is the thinp-test-suite uses intermediate linear
DM layers above the slower sd device (spindle/data) -- whereas in your
setup the origin device is direct to sd (8:0).
I would think the difference is because DM
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm tags/dm-3.9-fixes
to get the following device-mapper fixes for 3.9.
Thanks,
Alasdair
A set of device-mapper fixes for 3.9.
Fix reported data loss
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm tags/dm-3.9-fixes
to get the following device-mapper fixes for 3.9.
Thanks,
Alasdair
A set of device-mapper fixes for 3.9.
Fix reported data loss
On Fri, Mar 15, 2013 at 10:14:41AM +1100, Stephen Rothwell wrote:
> The patch in question has no commit message or headers at all ...
Now fixed. It escaped before I'd finished it...
Alasdair
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
1 - 100 of 518 matches
Mail list logo
