Should write-time tree-checker backported to v5.10?

Should write-time tree-checker backported to v5.10?

[Qu Wenruo]

Hi,

Since v5.10 is an LTS release, I'm wondering should we backport write
time tree-checker feature to v5.10?

There are already some reports of runtime memory bitflip get written to
disk and causing problems.

Unfortunately write-time tree-checker is only introduced in v5.11, one
version late.

Considering how many bitflips write-time tree-checker has caught (and
prevented corrupted data reaching disk), I think it's definitely worthy
to backport it to an LTS kernel.

Or is there any special requirement for LTS kernel to reject certain
features?

Thanks,
Qu

Re: Should write-time tree-checker backported to v5.10?

[Greg KH]

On Thu, Dec 30, 2021 at 08:06:49AM +0800, Qu Wenruo wrote:
> Hi,
> 
> Since v5.10 is an LTS release, I'm wondering should we backport write
> time tree-checker feature to v5.10?
> 
> There are already some reports of runtime memory bitflip get written to
> disk and causing problems.
> 
> Unfortunately write-time tree-checker is only introduced in v5.11, one
> version late.
> 
> Considering how many bitflips write-time tree-checker has caught (and
> prevented corrupted data reaching disk), I think it's definitely worthy
> to backport it to an LTS kernel.
> 
> Or is there any special requirement for LTS kernel to reject certain
> features?

Stable/LTS kernels do not get new features, sorry.  If someone wants
this feature, why not just use 5.15?

thanks,

greg k-h

Re: Should write-time tree-checker backported to v5.10?

[Qu Wenruo]

On 2021/12/30 14:55, Greg KH wrote:
> On Thu, Dec 30, 2021 at 08:06:49AM +0800, Qu Wenruo wrote:
>> Hi,
>>
>> Since v5.10 is an LTS release, I'm wondering should we backport write
>> time tree-checker feature to v5.10?
>>
>> There are already some reports of runtime memory bitflip get written to
>> disk and causing problems.
>>
>> Unfortunately write-time tree-checker is only introduced in v5.11, one
>> version late.
>>
>> Considering how many bitflips write-time tree-checker has caught (and
>> prevented corrupted data reaching disk), I think it's definitely worthy
>> to backport it to an LTS kernel.
>>
>> Or is there any special requirement for LTS kernel to reject certain
>> features?
>
> Stable/LTS kernels do not get new features, sorry.

OK, sorry to hear that.

>  If someone wants this feature, why not just use 5.15?

One thing is, this is not really a feature, but more like an extra
safenet to catch hardware problems.

In fact, just according to the reports in btrfs mail list, memory
bitflip is not that rare in the real world.

And any undetected bitflip reached disk will be later rejected by the
read time sanity check, causing a possibly unmountable fs.
(even we output exactly the reason why we reject the metadata, and with
those error messages, one can easily know it's a bitflip, it's still way
worse than rejecting the corrupted data at write time).

So I guess the only way to get full runtime sanity check is waiting for
the next LTS.

Thanks,
Qu
>
> thanks,
>
> greg k-h
>

Re: Should write-time tree-checker backported to v5.10?

[Greg KH]

On Thu, Dec 30, 2021 at 03:10:13PM +0800, Qu Wenruo wrote:
> 
> 
> On 2021/12/30 14:55, Greg KH wrote:
> > On Thu, Dec 30, 2021 at 08:06:49AM +0800, Qu Wenruo wrote:
> > > Hi,
> > > 
> > > Since v5.10 is an LTS release, I'm wondering should we backport write
> > > time tree-checker feature to v5.10?
> > > 
> > > There are already some reports of runtime memory bitflip get written to
> > > disk and causing problems.
> > > 
> > > Unfortunately write-time tree-checker is only introduced in v5.11, one
> > > version late.
> > > 
> > > Considering how many bitflips write-time tree-checker has caught (and
> > > prevented corrupted data reaching disk), I think it's definitely worthy
> > > to backport it to an LTS kernel.
> > > 
> > > Or is there any special requirement for LTS kernel to reject certain
> > > features?
> > 
> > Stable/LTS kernels do not get new features, sorry.
> 
> OK, sorry to hear that.
> 
> >  If someone wants this feature, why not just use 5.15?
> 
> One thing is, this is not really a feature, but more like an extra
> safenet to catch hardware problems.
> 
> In fact, just according to the reports in btrfs mail list, memory
> bitflip is not that rare in the real world.
> 
> And any undetected bitflip reached disk will be later rejected by the
> read time sanity check, causing a possibly unmountable fs.
> (even we output exactly the reason why we reject the metadata, and with
> those error messages, one can easily know it's a bitflip, it's still way
> worse than rejecting the corrupted data at write time).
> 
> So I guess the only way to get full runtime sanity check is waiting for
> the next LTS.

What exactly does the patches look like to backport this?

And what prevents people from using the 5.15 LTS kernel instead of 5.10
if they wish to have this additional protection?

thanks,

greg k-h

Re: Should write-time tree-checker backported to v5.10?

[Qu Wenruo]

On 2021/12/30 15:32, Greg KH wrote:
> On Thu, Dec 30, 2021 at 03:10:13PM +0800, Qu Wenruo wrote:
>>
>>
>> On 2021/12/30 14:55, Greg KH wrote:
>>> On Thu, Dec 30, 2021 at 08:06:49AM +0800, Qu Wenruo wrote:
>>>> Hi,
>>>>
>>>> Since v5.10 is an LTS release, I'm wondering should we backport write
>>>> time tree-checker feature to v5.10?
>>>>
>>>> There are already some reports of runtime memory bitflip get written to
>>>> disk and causing problems.
>>>>
>>>> Unfortunately write-time tree-checker is only introduced in v5.11, one
>>>> version late.
>>>>
>>>> Considering how many bitflips write-time tree-checker has caught (and
>>>> prevented corrupted data reaching disk), I think it's definitely worthy
>>>> to backport it to an LTS kernel.
>>>>
>>>> Or is there any special requirement for LTS kernel to reject certain
>>>> features?
>>>
>>> Stable/LTS kernels do not get new features, sorry.
>>
>> OK, sorry to hear that.
>>
>>>   If someone wants this feature, why not just use 5.15?
>>
>> One thing is, this is not really a feature, but more like an extra
>> safenet to catch hardware problems.
>>
>> In fact, just according to the reports in btrfs mail list, memory
>> bitflip is not that rare in the real world.
>>
>> And any undetected bitflip reached disk will be later rejected by the
>> read time sanity check, causing a possibly unmountable fs.
>> (even we output exactly the reason why we reject the metadata, and with
>> those error messages, one can easily know it's a bitflip, it's still way
>> worse than rejecting the corrupted data at write time).
>>
>> So I guess the only way to get full runtime sanity check is waiting for
>> the next LTS.
> 
> What exactly does the patches look like to backport this?

All my bad, the upstream commit is 8d47a0d8f794 ("btrfs: Do mandatory 
tree block check before submitting bio") which is already in v5.2, not 
v5.11.

So all these features are already in lts.

Really sorry for the noise.
Qu

> 
> And what prevents people from using the 5.15 LTS kernel instead of 5.10
> if they wish to have this additional protection?
> 
> thanks,
> 
> greg k-h
>