Re: LBS setup

[Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>]

Hi Wol

thanks for the answer.

My question is about "what to do?".
Not much what happened.

The log says we should copy some size
from somewhere to somewhere else.
The docs says this should be done
with array at rest.

Is there any documentation about this?
Should we just ignore the log?
What should be done, if any?

The log:

md1: echo current LBS to md/logical_block_size to prevent data loss issues from LBS changes.
               	Note: After setting, array will not be assembled in old kernels (<= 6.18)

The docs:

logical_block_size

Configure the array’s logical block size in bytes.
This attribute is only supported for 1.x meta.
*Write the value before starting array.* (emphasis mine)
The final array LBS uses the maximum between this
configuration and LBS of all combined devices.
Note that LBS cannot exceed PAGE_SIZE before RAID
supports folio.
WARNING: Arrays created on new kernel cannot be
assembled at old kernel due to padding check,
Set module parameter ‘check_new_feature’ to
false to bypass, but data loss may occur.

The kernel is pretty new, actually 7.1.3,
from Fedora.

Old kernels is for me no problem, it would
be a problem losing the array.

There is no procedure explained, documentation
is, for me, quite dry.
It would be good to have some comments from
whom wrote it (and the code as well).

Thanks,

bye,

pg

On Fri, Jul 10, 2026 at 06:10:47PM +0100, Wol wrote:
> On 10/07/2026 17:20, Piergiorgio Sartor wrote:
> > Hi again,
> > 
> > not sure, but has anybody comments
> > on the topic?
> 
> I don't understand what you're asking, but I do think I remember the events
> you're talking about.
> 
> Basically, some change accidentally slipped into the wild with a kernel,
> probably a 6.x, and people started creating kernels with the new kernel.
> 
> Then, as people started upgrading kernels, they suddenly realised that this
> change affected the raid format, such that  new kernels couldn't read old
> arrays, and vice versa. More importantly, and more dangerously, it led to
> arrays being trashed!
> 
> What to do? They couldn't pull old kernels obviously, there were too many
> arrays out there. They couldn't pull new kernels, there were already some
> arrays out there.
> 
> So they rushed out a fix, such that if a new kernel created an array, it
> flagged it as being a new array. If you booted a new kernel with an array
> that didn't have the flag IT WOULDN'T LOAD THE ARRAY. And they trusted to
> luck that people wouldn't downgrade an array and try to load a new array on
> an old kernel.
> 
> So this now meant that all of a sudden new kernels wouldn't boot on old
> systems, until the user explicitly set the flag on the array to say "this is
> an old-style array". If they happened to be upgrading from one of the few
> early new-style kernels, they could set the flag to "this is a new-style
> array".
> 
> Point is, this code was meant to make it very hard to upgrade your kernel
> without being prompted what sort of array you had, so that the kernel devs
> could try to ensure you didn't lose your array.
> 
> A pretty awful way of doing it, but nobody could think of anything better.
> 
> Hopefully that explains what's going on there, and you'll be able to work
> out your own answer from this information.
> 
> Cheers,
> Wol

-- 

piergiorgio