On 08.12.2020 12:37, Johannes Thumshirn wrote:
On 08/12/2020 13:22, Javier González wrote:
Good idea. Are you thinking of a sysfs entry to select the backend?
Not sure on this one, initially I thought of a sysfs file, but then
how would you do it. One "global" sysfs entry is probably a bad ide
On Tue, 2020-12-01 at 17:54 +0100, Christoph Hellwig wrote:
> Hi Jens,
>
> this series switches back from storing the gendisk + partno to storing
> a block_device pointer in struct bio. The reason is two fold: for one
> the new struct block_device actually is always available, removing the
> nee
On 07.12.2020 15:56, Hannes Reinecke wrote:
On 12/7/20 3:11 PM, Christoph Hellwig wrote:
So, I'm really worried about:
a) a good use case. GC in f2fs or btrfs seem like good use cases, as
does accelating dm-kcopyd. I agree with Damien that lifting dm-kcopyd
to common code would also
On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
>
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fal
On 08.12.2020 13:24, Johannes Thumshirn wrote:
On 08/12/2020 14:13, Javier González wrote:
On 08.12.2020 12:37, Johannes Thumshirn wrote:
On 08/12/2020 13:22, Javier González wrote:
Good idea. Are you thinking of a sysfs entry to select the backend?
Not sure on this one, initially I thought
On 08.12.2020 08:40, Johannes Thumshirn wrote:
On 07/12/2020 20:27, Javier González wrote:
Good point. We can share some performance data on how Simple Copy scales
in terms of bw / latency and the CPU usage. Do you have anything else in
mind?
With an emulation in the kernel, we could make the
On Mon, Dec 07, 2020 at 02:19:18PM +0100, Christoph Hellwig wrote:
> Unconditionally call set_disk_ro now that it only updates the hardware
> state. This allows to properly set up the Linux devices read-only when
> the controller turns a previously writable namespace read-only.
>
> Signed-off-by:
On Fri, 04 Dec 2020 02:33:36 PST (-0800), Christoph Hellwig wrote:
What is the advantage over simply using nbd?
There's a short bit about that in the cover letter (and in some talks), but
I'll expand on it here -- I suppose my most important question is "is this
interesting enough to take upstr
On 07.12.2020 15:11, Christoph Hellwig wrote:
So, I'm really worried about:
a) a good use case. GC in f2fs or btrfs seem like good use cases, as
does accelating dm-kcopyd. I agree with Damien that lifting dm-kcopyd
to common code would also be really nice. I'm not 100% sure it should
On 2020-12-07 9:56 a.m., Hannes Reinecke wrote:
On 12/7/20 3:11 PM, Christoph Hellwig wrote:
So, I'm really worried about:
a) a good use case. GC in f2fs or btrfs seem like good use cases, as
does accelating dm-kcopyd. I agree with Damien that lifting dm-kcopyd
to common code woul
On 08.12.2020 07:44, Hannes Reinecke wrote:
On 12/7/20 11:12 PM, Douglas Gilbert wrote:
On 2020-12-07 9:56 a.m., Hannes Reinecke wrote:
On 12/7/20 3:11 PM, Christoph Hellwig wrote:
So, I'm really worried about:
a) a good use case. GC in f2fs or btrfs seem like good use cases, as
does
On Tue, 2020-12-08 at 12:04 +0100, Christoph Hellwig wrote:
> can you send me details of your device mapper setup, e.g. which targets
> are used, are they used on top of whole device or partitions. Do you
> use partitions on top of the dm devices? Are any other stacking devices
> involved?
It is
On Wed, Dec 09 2020 at 4:58pm -0500,
Song Liu wrote:
> This reverts commit f0e90b6c663a7e3b4736cb318c6c7c589f152c28.
>
> Matthew Ruffell reported data corruption in raid10 due to the changes
> in discard handling [1]. Revert these changes before we find a proper fix.
>
> [1] https://bugs.launc
On Wed, Dec 09 2020 at 4:58pm -0500,
Song Liu wrote:
> This reverts commit f0e90b6c663a7e3b4736cb318c6c7c589f152c28.
>
> Matthew Ruffell reported data corruption in raid10 due to the changes
> in discard handling [1]. Revert these changes before we find a proper fix.
>
> [1] https://bugs.launc
On 12/7/20 10:55 AM, Palmer Dabbelt wrote:
> All in all, I've found it a bit hard to figure out what sort of interest
> people
> have in dm-user: when I bring this up I seem to run into people who've done
> similar things before and are vaguely interested, but certainly nobody is
> chomping at the
Hi Song,
I love your patch! Perhaps something to improve:
[auto build test WARNING on dm/for-next]
[also build test WARNING on linux/master linus/master v5.10-rc7 next-20201209]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
Hi Song,
I love your patch! Perhaps something to improve:
[auto build test WARNING on dm/for-next]
[also build test WARNING on linux/master linus/master v5.10-rc7 next-20201209]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
Jens, can you pick this up for 5.11?
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
18 matches
Mail list logo
