LBS setup

LBS setup

[Piergiorgio Sartor]

Hi all,

I've some questions about some recent
report from kernel.
I assume from 7.x.y, from what I understood.
Not sure about the <= 6.18 reported.

In the boot log there is:

md0: 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)

I found the docs stating:

logical_block_size
	... Write the value before starting array. ...

Now, should we really copy the value from:

/sys/class/block/md0/queue/logical_block_size

to:

/sys/class/block/md0/md/logical_block_size

???

Note, the first in my system is 512, the
second is 0.

Second, the docs says "before starting array".
In case this is due (copy the value), how to do
for a system array?
I mean, the array where the whole OS lies.

If needed, is there any way to do this automatically?
Using mdadm or something?

Thanks,

bye,

-- 

piergiorgio

Re: LBS setup

[Piergiorgio Sartor]

Hi again,

not sure, but has anybody comments
on the topic?

Thanks,

bye,

pg

On Sun, May 24, 2026 at 12:27:27PM +0200, Piergiorgio Sartor wrote:
> Hi all,
> 
> I've some questions about some recent
> report from kernel.
> I assume from 7.x.y, from what I understood.
> Not sure about the <= 6.18 reported.
> 
> In the boot log there is:
> 
> md0: 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)
> 
> I found the docs stating:
> 
> logical_block_size
> 	... Write the value before starting array. ...
> 
> Now, should we really copy the value from:
> 
> /sys/class/block/md0/queue/logical_block_size
> 
> to:
> 
> /sys/class/block/md0/md/logical_block_size
> 
> ???
> 
> Note, the first in my system is 512, the
> second is 0.
> 
> Second, the docs says "before starting array".
> In case this is due (copy the value), how to do
> for a system array?
> I mean, the array where the whole OS lies.
> 
> If needed, is there any way to do this automatically?
> Using mdadm or something?
> 
> Thanks,
> 
> bye,
> 
> -- 
> 
> piergiorgio
> 

-- 

piergiorgio

Re: LBS setup

[Wol]

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

Re: LBS setup

[Piergiorgio Sartor]

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

Re: LBS setup

[Wol]

On 10/07/2026 18:54, Piergiorgio Sartor wrote:
> 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)

Ah. Personally I wouldn't do anything, then. Are you using any systems 
with kernel 6.18 or earlier?

Are you likely to use any kernels 6.18 or earlier in the future?

If the answer to both questions is no, then you're not going to have any 
trouble ...

Cheers,
Wol

Re: LBS setup

[Piergiorgio Sartor]

On Fri, Jul 10, 2026 at 09:43:56PM +0100, Wol wrote:
> On 10/07/2026 18:54, Piergiorgio Sartor wrote:
> > 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)
> 
> Ah. Personally I wouldn't do anything, then. Are you using any systems with
> kernel 6.18 or earlier?
> 
> Are you likely to use any kernels 6.18 or earlier in the future?
> 
> If the answer to both questions is no, then you're not going to have any
> trouble ...

Thanks again for the answer.

Nevertheless, sorry if I insist.
What I understand from the log message is
that if I do *not* copy the LBS I can get
data loss. If I do copy the LBS, I will
not be anymore backward compatible.

This backward compatibility does not seem
interesting for me, hence I should copy
this LBS.
Which then begs the question: how?

I mean, this seems the logical conclusion
from what I understood from the log.

Also, why to have this log in the first place?
The kernel is 7.1.3, so if everything would
be fine with it, no need to log anything.

I do not know...

Anyway, sorry again if I bother...

Thanks,

bye,

-- 

piergiorgio