On 18.09.2025 17:00, Harald Freudenberger wrote:
> On 2025-09-11 17:58, Mikulas Patocka wrote:
>> On Thu, 11 Sep 2025, Ingo Franzki wrote:
>>
>>> >> So, it looks like a dm-crypt bug.
>>> >>
>>> >> Please, revert my patches and run the same test on a clean 6.17.0-rc5
>>> >> just
>>> >> to verify th
Mikulas,
> The warnings are caused by the fact that io_min is 512 and physical
> block size is 4096.
>
> If there's chunk-less raid, such as raid1, io_min shouldn't be set to
> zero because it would be raised to 512 and it would trigger the
> warning.
Reviewed-by: Martin K. Petersen
--
Marti
On Sep 18, 2025 / 13:15, Mikulas Patocka wrote:
[...]
> Thanks for testing it. I fixed it, I folded the fix into the existing
> patch. You can get it here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/log/?h=for-next
Mikulas, thank you for fixing it. I found tha
Hi Heinz
On Thu, Sep 18, 2025 at 9:55 PM Heinz Mauelshagen wrote:
>
> The dm-raid code was using hardcoded integer values to represent the
> read-only/read-write state
> of RAID arrays instead of the proper enumeration constants defined in the
> md_ro_state enumerator type.
>
> Changes:
>
> - R
On Thu, Sep 18, 2025 at 04:27:14PM -0400, Mike Snitzer wrote:
> On Thu, Sep 18, 2025 at 09:16:42AM -0700, Keith Busch wrote:
> > From: Keith Busch
> >
> > Most storage devices can handle DMA for data that is not aligned to the
> > sector block size. The block and filesystem layers have introduced
On Thu, Sep 18, 2025 at 09:16:42AM -0700, Keith Busch wrote:
> From: Keith Busch
>
> Most storage devices can handle DMA for data that is not aligned to the
> sector block size. The block and filesystem layers have introduced
> updates to allow that kind of memory alignment flexibility when
> pos
On Thu, Sep 18, 2025 at 09:16:42AM -0700, Keith Busch wrote:
> + bio_advance_iter_single(ctx->bio_in, &ctx->iter_in, len);
> + bytes -= len;
> + } while (bytes);
> +
> + sg_mark_end(sg_in);
> + sg_in = dmreq->sg_in[0];
Err, there should be an '&' in there, "&dmr
On 9/9/25 1:18 PM, Ingo Franzki wrote:
Please, revert my patches and run the same test on a clean 6.17.0-rc5 just
to verify that the patches do not introduce the bug.
With your patches reverted the combined mode fails the same way as with your
patches.
So they did not introduce the bug.
Plea
Store the READ KEYS response and the prout_param_descriptor on the stack
to avoid having to fail these functions for allocation reasons. Don't
explicitly check for additional_length == 0, since the for-loop already
handles that. Also cleanup formatting issues,remove redundant messages,
and reduce
From: Keith Busch
Most storage devices can handle DMA for data that is not aligned to the
sector block size. The block and filesystem layers have introduced
updates to allow that kind of memory alignment flexibility when
possible.
dm-crypt, however, currently constrains itself to aligned memory
On 2025-09-11 17:58, Mikulas Patocka wrote:
On Thu, 11 Sep 2025, Ingo Franzki wrote:
>> So, it looks like a dm-crypt bug.
>>
>> Please, revert my patches and run the same test on a clean 6.17.0-rc5 just
>> to verify that the patches do not introduce the bug.
>
> With your patches reverted the c
The dm-raid code was using hardcoded integer values to represent the
read-only/read-write state
of RAID arrays instead of the proper enumeration constants defined in the
md_ro_state enumerator type.
Changes:
- Replace hardcoded integers with the appropriate md_ro_state enumerator values
- Add
On Thu, 18 Sep 2025, Shinichiro Kawasaki wrote:
> On Sep 15, 2025 / 17:42, Mikulas Patocka wrote:
> [...]
> > If the table has only linear targets and there is just one underlying
> > device, we can optimize REQ_PREFLUSH with data - we don't have to split
> > it to two bios - a flush and a writ
On 9/11/25 7:56 PM, Benjamin Marzinski wrote:
On Wed, Sep 10, 2025 at 09:41:57PM +0200, Xose Vazquez Perez wrote:
Source:
https://dl.acronis.com/u/software-defined/html/AcronisCyberInfrastructure_3_5_users_guide_en-US/accessing-iscsi/accessing-iscsi-targets-from-linux.html
Cc: Martin Wilck
C
14 matches
Mail list logo