lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <01233a11-9f65-4851-ad7e-d0b61c496339@linux.ibm.com>
Date: Fri, 20 Jun 2025 19:59:46 +0530
From: Nilay Shroff <nilay@...ux.ibm.com>
To: John Garry <john.g.garry@...cle.com>, agk@...hat.com, snitzer@...nel.org,
        mpatocka@...hat.com, song@...nel.org, yukuai3@...wei.com, hch@....de,
        axboe@...nel.dk
Cc: dm-devel@...ts.linux.dev, linux-kernel@...r.kernel.org,
        linux-raid@...r.kernel.org, linux-block@...r.kernel.org,
        ojaswin@...ux.ibm.com, martin.petersen@...cle.com
Subject: Re: [PATCH v2 0/5] block/md/dm: set chunk_sectors from stacked dev
 stripe size



On 6/18/25 2:07 PM, John Garry wrote:
> This value in io_min is used to configure any atomic write limit for the
> stacked device. The idea is that the atomic write unit max is a
> power-of-2 factor of the stripe size, and the stripe size is available
> in io_min.
> 
> Using io_min causes issues, as:
> a. it may be mutated
> b. the check for io_min being set for determining if we are dealing with
> a striped device is hard to get right, as reported in [0].
> 
> This series now sets chunk_sectors limit to share stripe size.
> 
> [0] https://lore.kernel.org/linux-block/888f3b1d-7817-4007-b3b3-1a2ea04df771@linux.ibm.com/T/#mecca17129f72811137d3c2f1e477634e77f06781
> 
> Based on v6.16-rc2

I have validated this patchset using an NVMe disk supporting atomic write and
native NVMe multipath. I have also validated dm-stripe and raid configuration.
Overall the patchset looks good to me and fixes the issue I posted[1] earlier 
with my NVMe disk.

[1]: https://lore.kernel.org/linux-block/888f3b1d-7817-4007-b3b3-1a2ea04df771@linux.ibm.com/T/#mecca17129f72811137d3c2f1e477634e77f06781

Thanks,
--Nilay

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ