On 5/20/24 12:20, Nitesh Shetty wrote:
Add device limits as sysfs entries,
- copy_max_bytes (RW)
- copy_max_hw_bytes (RO)
Above limits help to split the copy payload in block layer.
copy_max_bytes: maximum total length of copy in single payload.
copy_max_hw_bytes: Reflects the de
On May 20, 2024 / 11:58, Bryan Gurney wrote:
> Add a general functionality test for the dm-dust device-mapper test
> target. Test the addition of bad blocks, and the clearing of bad
> blocks after a write is performed to the test device.
>
> Signed-off-by: Bryan Gurney
Hi Bryan, thank you for t
On Tue, May 21, 2024 at 9:09 AM Yu Kuai wrote:
>
> Thanks for the test! Since raid10 has the same problem as well, then the
> problem seems to be more common in raid. And related code to raid10 is
> more simpler, attached is a patch to add debuginfo to raid10.
>
> BTW, Xiao can reporduce the prob
On Tue 21 May 2024 at 11:25, Xiao Ni wrote:
On Mon, May 20, 2024 at 8:38 PM Su Yue wrote:
On Thu 09 May 2024 at 09:18, Yu Kuai
wrote:
> From: Yu Kuai
>
> The new helpers will get current sync_action of the array,
> will
> be used
> in later patches to make code cleaner.
>
> Signed-of
On Mon, May 20, 2024 at 8:38 PM Su Yue wrote:
>
>
> On Thu 09 May 2024 at 09:18, Yu Kuai
> wrote:
>
> > From: Yu Kuai
> >
> > The new helpers will get current sync_action of the array, will
> > be used
> > in later patches to make code cleaner.
> >
> > Signed-off-by: Yu Kuai
> > ---
> > driver
skipping tests for multipath, which is removed in upstream 6.8+
> > kernels
> > test: skipping tests for linear, which is removed in upstream 6.8+ kernels
> > Testing on linux-6.9.0-rc2-00023-gf092583596a2 kernel
> > /root/mdadm/tests/07reshape5intr... FAILED - see /var/tmp/07reshape5intr.log
> > and /var/tmp/fail07reshape5intr.log for details
> > (KNOWN BROKEN TEST: always fails)
> >
> > So, since this test is marked BROKEN.
> >
> > Please share the whole log, and is it possible to share the two logs?
>
>
> we only captured one log as attached log-18effaab5f.
> also attached parent log FYI.
>
>
> >
> > Thanks,
> > Kuai
> >
> > >
> > >
> > >
> > > The kernel config and materials to reproduce are available at:
> > > https://download.01.org/0day-ci/archive/20240520/202405202204.4e3dc662-oliver.s...@intel.com
> > >
> > >
> > >
> >
attach the two logs
if possible:
/var/tmp/07reshape5intr.log and /var/tmp/fail07reshape5intr.log
Thanks for the test, we really need a per patch CI.
Kuai
Thanks,
Kuai
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20240520/202405202204.4e3dc662-oliver.s...@intel.com
skipping tests for multipath, which is removed in upstream 6.8+
> kernels
> test: skipping tests for linear, which is removed in upstream 6.8+ kernels
> Testing on linux-6.9.0-rc2-00023-gf092583596a2 kernel
> /root/mdadm/tests/07reshape5intr... FAILED - see /var/tmp/07reshape
Hi,
在 2024/05/20 19:51, Su Yue 写道:
On Thu 09 May 2024 at 09:18, Yu Kuai wrote:
From: Yu Kuai
The new helpers will get current sync_action of the array, will be used
in later patches to make code cleaner.
Signed-off-by: Yu Kuai
---
drivers/md/md.c | 64 ++
it possible to share the two logs?
Thanks,
Kuai
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20240520/202405202204.4e3dc662-oliver.s...@intel.com
Hi,
在 2024/05/20 18:38, Changhui Zhong 写道:
On Mon, May 20, 2024 at 10:55 AM Yu Kuai wrote:
Hi, Changhui
在 2024/05/20 8:39, Changhui Zhong 写道:
[czhong@vm linux-block]$ git bisect bad
060406c61c7cb4bbd82a02d179decca9c9bb3443 is the first bad commit
commit 060406c61c7cb4bbd82a02d179decca9c9bb3
On Mon, May 20, 2024 at 06:03:11PM -0400, Mike Snitzer wrote:
> On Mon, May 20, 2024 at 10:12:37PM +0200, Christoph Hellwig wrote:
> > On Mon, May 20, 2024 at 01:17:46PM -0400, Mike Snitzer wrote:
> > > Doubt there was anything in fstests setting max discard user limit
> > > (max_user_discard_secto
On 5/20/24 03:20, Nitesh Shetty wrote:
+ if (blk_rq_nr_phys_segments(req) != BLK_COPY_MAX_SEGMENTS)
+ return status;
Why is this check necessary?
+ /*
+* First bio contains information about destination and last bio
+* contains information about sourc
A multipath device alias of dm-1 is valid, albeit a really bad idea.
Make sure that find_mp_by_str() is only checking for multipath devices
by minor number for strings that really are of the form dm-, and
if the minor-number check fails, check if the string is an alias, just
to be safe.
Signed-off
If the device string is not an alias, check if it's a wwid. This allows
multipathd commands to use WWIDs for $map arguments. In find_mp_by_wwid,
only check strings that are small enough to be WWIDs.
Signed-off-by: Benjamin Marzinski
---
libmultipath/structs.c | 4 +++-
1 file changed, 3 insertio
The multipathd commands with a $map argument will only accept
dm- and aliases for $map. Make them accept WWIDs as well. Also,
change find_mp_by_str() to not skip devices with aliases of the form
dm-, which are horrible names, but
still valid.
Benjamin Marzinski (2):
libmultipath: accept poorly c
On 5/20/24 03:20, Nitesh Shetty wrote:
This is a prep patch to enable copy trace capability.
At present only zoned null_block is using trace, so we decoupled trace
and zoned dependency to make it usable in null_blk driver also.
Reviewed-by: Bart Van Assche
On 5/20/24 03:20, Nitesh Shetty wrote:
Setting copy_offload_supported flag to enable offload.
I think that the description of this patch should explain why it is safe
to set the 'copy_offload_supported' flag for the dm-linear driver.
Thanks,
Bart.
On 5/20/24 03:20, Nitesh Shetty wrote:
Upon arrival of source bio we merge these two bio's and send
corresponding request down to device driver.
bios with different operation types must not be merged.
+static enum bio_merge_status bio_attempt_copy_offload_merge(struct request
*req,
+
On 5/20/24 03:20, Nitesh Shetty wrote:
4. This bio is merged with the request containing the destination info.
bios with different operation types must never be merged. From attempt_merge():
if (req_op(req) != req_op(next))
return NULL;
Thanks,
Bart.
On 5/20/24 03:20, Nitesh Shetty wrote:
+static ssize_t queue_copy_max_show(struct request_queue *q, char *page)
+{
+ return sprintf(page, "%llu\n", (unsigned long long)
+ q->limits.max_copy_sectors << SECTOR_SHIFT);
+}
+
+static ssize_t queue_copy_max_store(struct reque
On Mon, May 20, 2024 at 10:12:37PM +0200, Christoph Hellwig wrote:
> On Mon, May 20, 2024 at 01:17:46PM -0400, Mike Snitzer wrote:
> > Doubt there was anything in fstests setting max discard user limit
> > (max_user_discard_sectors) in Ted's case. blk_set_stacking_limits()
> > sets max_user_discard
On Mon, May 20, 2024 at 01:17:46PM -0400, Mike Snitzer wrote:
> Doubt there was anything in fstests setting max discard user limit
> (max_user_discard_sectors) in Ted's case. blk_set_stacking_limits()
> sets max_user_discard_sectors to UINT_MAX, so given the use of
> min(lim->max_hw_discard_sectors
[replying for completeness to explain what I think is happening for
the issue Ted reported]
On Mon, May 20, 2024 at 11:54:53AM -0400, Mike Snitzer wrote:
> On Mon, May 20, 2024 at 05:44:25PM +0200, Christoph Hellwig wrote:
> > On Mon, May 20, 2024 at 11:39:14AM -0400, Mike Snitzer wrote:
> > > Tha
Add a general functionality test for the dm-dust device-mapper test
target. Test the addition of bad blocks, and the clearing of bad
blocks after a write is performed to the test device.
Signed-off-by: Bryan Gurney
---
tests/dm/002 | 40
tests/dm/002
On Mon, May 20, 2024 at 05:44:25PM +0200, Christoph Hellwig wrote:
> On Mon, May 20, 2024 at 11:39:14AM -0400, Mike Snitzer wrote:
> > That's fair. My criticism was more about having to fix up DM targets
> > to cope with the new normal of max_discard_sectors being set as a
> > function of max_hw_d
On Mon, May 20, 2024 at 11:47:54AM -0400, Mike Snitzer wrote:
> Maybe update blk_validate_limits() to ensure max_discard_sectors is a
> factor of discard_granularity?
That's probably a good idea. I'm travelling currently so I'll probably
need a day to two to get to this, feel free to do it yourse
On Mon, May 20, 2024 at 11:39:14AM -0400, Mike Snitzer wrote:
> On Mon, May 20, 2024 at 05:06:53PM +0200, Christoph Hellwig wrote:
>
> > This is probably my fault, I actually found this right at the time
> > of the original revert of switching dm to the limits API, and then
> > let it slip as the
On Mon, May 20, 2024 at 11:39:14AM -0400, Mike Snitzer wrote:
> That's fair. My criticism was more about having to fix up DM targets
> to cope with the new normal of max_discard_sectors being set as a
> function of max_hw_discard_sectors and max_user_discard_sectors.
>
> With stacked devices in p
On Mon, May 20, 2024 at 05:06:53PM +0200, Christoph Hellwig wrote:
> On Sun, May 19, 2024 at 01:42:00AM -0400, Mike Snitzer wrote:
> > > This being one potential fix from code inspection I've done to this
> > > point, please see if it resolves your fstests failures (but I haven't
> > > actually loo
On Sun, May 19, 2024 at 01:42:00AM -0400, Mike Snitzer wrote:
> > This being one potential fix from code inspection I've done to this
> > point, please see if it resolves your fstests failures (but I haven't
> > actually looked at those fstests yet _and_ I still need to review
> > commits d690cb8ae
/var/tmp/fail07reshape5intr.log for details
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20240520/202405202204.4e3dc662-oliver.s...@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
On Mon, May 20, 2024 at 04:48:31PM +0200, Mikulas Patocka wrote:
> dm-integrity could set discard_granularity lower than the logical block
> size. This could result in failures when sending discard requests to
> dm-integrity. This patch fixes discard_granularity.
What kernel was this reported on?
On 2024/05/20 12:20, Nitesh Shetty wrote:
> We add two new opcode REQ_OP_COPY_DST, REQ_OP_COPY_SRC.
> Since copy is a composite operation involving src and dst sectors/lba,
> each needs to be represented by a separate bio to make it compatible
> with device mapper.
Why ? The beginning of the sente
dm-integrity could set discard_granularity lower than the logical block
size. This could result in failures when sending discard requests to
dm-integrity. This patch fixes discard_granularity.
Signed-off-by: Mikulas Patocka
Reported-by: Eric Wheeler
Cc: sta...@vger.kernel.org
---
drivers/md/dm
On 2024/05/20 12:20, Nitesh Shetty wrote:
> Add device limits as sysfs entries,
> - copy_max_bytes (RW)
> - copy_max_hw_bytes (RO)
>
> Above limits help to split the copy payload in block layer.
> copy_max_bytes: maximum total length of copy in single payload.
> copy_max_hw_bytes: Refl
On Mon, May 20, 2024 at 02:42:34PM +0200, Mikulas Patocka wrote:
>
>
> On Thu, 16 May 2024, Ming Lei wrote:
>
> > On Wed, May 15, 2024 at 03:28:11PM +0200, Mikulas Patocka wrote:
> > > If we allocate a bio that is larger than NVMe maximum request size, attach
> > > integrity metadata to it and s
On Wed, 15 May 2024, Jens Axboe wrote:
> On 5/15/24 7:28 AM, Mikulas Patocka wrote:
> > @@ -177,9 +177,9 @@ static inline int blk_integrity_rq(struc
> > return 0;
> > }
> >
> > -static inline struct bio_vec *rq_integrity_vec(struct request *rq)
> > +static inline struct bio_vec rq_integr
On Thu, 16 May 2024, Ming Lei wrote:
> On Wed, May 15, 2024 at 03:28:11PM +0200, Mikulas Patocka wrote:
> > If we allocate a bio that is larger than NVMe maximum request size, attach
> > integrity metadata to it and send it to the NVMe subsystem, the integrity
> > metadata will be corrupted.
>
On Thu 09 May 2024 at 09:18, Yu Kuai
wrote:
From: Yu Kuai
The new helpers will get current sync_action of the array, will
be used
in later patches to make code cleaner.
Signed-off-by: Yu Kuai
---
drivers/md/md.c | 64
+
drivers/md/md
Implementation is based on existing read and write infrastructure.
copy_max_bytes: A new configfs and module parameter is introduced, which
can be used to set hardware/driver supported maximum copy limit.
Only request based queue mode will support for copy offload.
Added tracefs support to copy IO
This is a prep patch to enable copy trace capability.
At present only zoned null_block is using trace, so we decoupled trace
and zoned dependency to make it usable in null_blk driver also.
Reviewed-by: Hannes Reinecke
Signed-off-by: Nitesh Shetty
Signed-off-by: Anuj Gupta
---
drivers/block/nul
Setting copy_offload_supported flag to enable offload.
Reviewed-by: Hannes Reinecke
Signed-off-by: Nitesh Shetty
---
drivers/md/dm-linear.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/md/dm-linear.c b/drivers/md/dm-linear.c
index 2d3e186ca87e..cfec2fac28e1 100644
--- a/drivers/m
Before enabling copy for dm target, check if underlying devices and
dm target support copy. Avoid split happening inside dm target.
Fail early if the request needs split, currently splitting copy
request is not supported.
Signed-off-by: Nitesh Shetty
---
drivers/md/dm-table.c | 37 ++
Add support for handling nvme_cmd_copy command on target.
For bdev-ns if backing device supports copy offload we call device copy
offload (blkdev_copy_offload).
In case of absence of device copy offload capability, we use copy emulation
(blkdev_copy_emulation)
For file-ns we call vfs_copy_file_ra
Current design only supports single source range.
We receive a request with REQ_OP_COPY_DST.
Parse this request which consists of dst(1st) and src(2nd) bios.
Form a copy command (TP 4065)
trace event support for nvme_copy_cmd.
Set the device copy limits to queue limits.
Reviewed-by: Hannes Reinec
For direct block device opened with O_DIRECT, use blkdev_copy_offload to
issue device copy offload, or use splice_copy_file_range in case
device copy offload capability is absent or the device files are not open
with O_DIRECT.
Reviewed-by: Hannes Reinecke
Signed-off-by: Anuj Gupta
Signed-off-by:
From: Anuj Gupta
This is a prep patch. Allow copy_file_range to work for block devices.
Relaxing generic_copy_file_checks allows us to reuse the existing infra,
instead of adding a new user interface for block copy offload.
Change generic_copy_file_checks to use ->f_mapping->host for both inode_i
For the devices which does not support copy, copy emulation is added.
It is required for in-kernel users like fabrics, where file descriptor is
not available and hence they can't use copy_file_range.
Copy-emulation is implemented by reading from source into memory and
writing to the corresponding d
Introduce blkdev_copy_offload to perform copy offload.
Issue REQ_OP_COPY_DST with destination info along with taking a plug.
This flows till request layer and waits for src bio to arrive.
Issue REQ_OP_COPY_SRC with source info and this bio reaches request
layer and merges with dst request.
For any
We add two new opcode REQ_OP_COPY_DST, REQ_OP_COPY_SRC.
Since copy is a composite operation involving src and dst sectors/lba,
each needs to be represented by a separate bio to make it compatible
with device mapper.
We expect caller to take a plug and send bio with destination information,
followed
Add device limits as sysfs entries,
- copy_max_bytes (RW)
- copy_max_hw_bytes (RO)
Above limits help to split the copy payload in block layer.
copy_max_bytes: maximum total length of copy in single payload.
copy_max_hw_bytes: Reflects the device supported maximum limit.
Signed-off
The patch series covers the points discussed in the past and most recently
in LSFMM'24[0].
We have covered the initial agreed requirements in this patch set and
further additional features suggested by the community.
This is next iteration of our previous patch set v19[1].
Copy offload is performe
On Mon, May 20, 2024 at 3:27 PM Yu Kuai wrote:
>
> Hi,
>
> 在 2024/05/20 10:55, Yu Kuai 写道:
> > Hi, Changhui
> >
> > 在 2024/05/20 8:39, Changhui Zhong 写道:
> >> [czhong@vm linux-block]$ git bisect bad
> >> 060406c61c7cb4bbd82a02d179decca9c9bb3443 is the first bad commit
> >> commit 060406c61c7cb4bbd
On Mon, May 20, 2024 at 10:55 AM Yu Kuai wrote:
>
> Hi, Changhui
>
> 在 2024/05/20 8:39, Changhui Zhong 写道:
> > [czhong@vm linux-block]$ git bisect bad
> > 060406c61c7cb4bbd82a02d179decca9c9bb3443 is the first bad commit
> > commit 060406c61c7cb4bbd82a02d179decca9c9bb3443
> > Author: Yu Kuai
> > Da
Hi,
在 2024/05/20 10:55, Yu Kuai 写道:
Hi, Changhui
在 2024/05/20 8:39, Changhui Zhong 写道:
[czhong@vm linux-block]$ git bisect bad
060406c61c7cb4bbd82a02d179decca9c9bb3443 is the first bad commit
commit 060406c61c7cb4bbd82a02d179decca9c9bb3443
Author: Yu Kuai
Date: Thu May 9 20:38:25 2024 +0800
56 matches
Mail list logo
