News: 1608039906

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

The first point release for Linux 5.10 came out barely a day later because storage bugs broke RAID6 partitions

(2020/12/15)


Hopefully not shooting for parity with Windows, the Linux team followed the weekend release of version 5.10 of the kernel with... an update barely a day later.

"Nothing makes me go 'we need another week'," said Linux supremo Linus Torvalds [1]of Sunday's emission .

However, perhaps a few more days might have been handy as kernel maintainer Greg Kroah-Hartman saw fit to push out a point release for 5.10 LTS in order to deal with storage bugs sufficiently serious to merit immediate action.

There are just the [2]two changes in the release , both reverting earlier changes. One of those was a "fix" for discard limits for RAID1 and RAID10, while the other was a change of the chunk_sectors variable from int to unsigned.

Linux kernel's Kroah-Hartman: We're not struggling to get new coders, it's code review that's the bottleneck [3]READ MORE

The changes appeared to have caused issues with the mounting of RAID devices (RAID6 at least) judging by [4]mailing list comments , with Kroah-Hartman noting "It causes problems :(" in the [5]release notes against both reverts .

More worryingly, things were apparently fine in rc7, the last release before Torvalds unleashed 5.10 upon a waiting world. Fortunately, developers keen to have a crack at the final release spotted the problems and the fix was done. Bugs around storage tend to make people a little jittery; just ask Microsoft about that [6]document-destroying Windows 10 October 2018 Update .

As with any major operating system release, the lesson remains the same: give it a few point releases before installation unless you're prepared for a potentially hurried rollback.

The last LTS release of the Linux kernel, 5.4 – released in November 2019 – saw just a few days between initial release and the [7]first update on 25 November . The latest has cut this down to barely a day. One can but hope the time will not be measured in hours next time around. ®

Get our [8]Tech Resources



[1] https://www.theregister.com/2020/12/14/linux_5_10_released/

[2] https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.1

[3] https://www.theregister.com/2020/10/26/linux_kernel_intel/

[4] https://lkml.org/lkml/2020/12/14/527

[5] https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.1

[6] https://www.theregister.com/2018/10/10/microsoft_windows_deletion_bug/

[7] https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.1

[8] https://whitepapers.theregister.com/

karlkarl

"We're not taking cues from Windows now, are we?"

If the Linux ecosystem was such that the kernel was packaged and forcibly shoved onto our machines, then yes, that would be the case.

Luckily individual downstream distros tend to do their own testing and packaging which usually catches this kind of regression. Yes, bugs happen but the key is to keep the user in control which is something that companies are starting to fail to provide.

That said, I am fairly impressed this doesn't happen more often. Linux is not only getting inevitably complex but it is also being pushed around by a number of competing entities (both ethical and non-ethical) trying to integrate their own agendas. I am very surprised we don't hit more technical conflicts and thus regressions. Especially since from my experience, code coming from commercial vendors is typically shoddy and bodged compared to open-source enthusiasts who show some passion and correctness for their trade.

Speed

HildyJ

M$ sins are much greater than anything Linux has done.

But the code to deadline is never a good idea.

"Nothing makes me go 'we need another week'." This makes no sense whether it's said by Satya Nadella or Linus Torvalds .

John Robson

Bug found on point release.

No one should have this on any non dev machine anyway, so the comparison with the Micros~1 bug, which was pushed out to production machines, is somewhat contrived.

The open nature also allowed the specific patches to be identified and rolled back trivially, and from what little I've read it was a mounting error, not a data loss error.

RAID 6 ...

Anonymous Coward

... is crap anyway. Use RAIDZ2

Ok I'm trolling a bit, but not entirely :-D

Re: RAID 6 ... nor the Fs

Colin Bull 1

I have seen RAID 5 fall over catastrophically so many times ..

This should be compulsory reading

http://www.baarf.dk/BAARF/BAARF2.html

Needs bringing up to date include the latest marketing wheezes

BTRFS has a bright future behind it

Anonymous Coward

I used to be very excited when BTRFS came on the scene but gradually it was, seemingly perpetually, always just a year or two before it was ready for production. Since then it has suffered some poor data loss bugs and it's not hard to find anecdotes from people with unrecoverable data issues due to powerloss etc. Thirteen years on and I still wouldn't trust my data to it.

Maryann's Law:
You can always find what you're not looking for.