On Wed 2018-03-07 22:11:13, David Woodhouse wrote:
On Wed, 2018-03-07 at 14:08 -0800, Steve deRosier wrote:
To clarify one thing: the reason for this is MLC has actually never been supported, nor worked properly. The fact that it kinda worked was incidental and the cause of major problems for people due to that not being clear. This patch only makes it explicit and avoids people mistakenly trying to use UBIFS on MLC flash and risking their data and products. To me, that's what's important.
This is an important patch, even if all it does is keep people from loosing data. It also changes the conversation from "I have a corrupted UBIFS device, BTW it's on MLC..." to "What can we do to get UBIFS to work on MLC".
Well, for -stable I'd suggest printk(KERN_ALERT ...) but keep the system running.
This is a bug fix.
UBI on MLC never worked. It was a bug that we ever permitted it. This is now fixed.
Yeah, well, so lets say I have a working hardware (maybe using read-only UBI on MLC), update to next stable kernel, and now kernel refuses to see the partition.
I'll certainly not consider this patch a bug fix.
Removing support for hardware that "only works by mistake" may be good idea, but maybe it is slightly too surprising for a -stable.
Pavel
Hi Pavel,
On Wed, 7 Mar 2018 23:17:33 +0100 Pavel Machek pavel@ucw.cz wrote:
On Wed 2018-03-07 22:11:13, David Woodhouse wrote:
On Wed, 2018-03-07 at 14:08 -0800, Steve deRosier wrote:
To clarify one thing: the reason for this is MLC has actually never been supported, nor worked properly. The fact that it kinda worked was incidental and the cause of major problems for people due to that not being clear. This patch only makes it explicit and avoids people mistakenly trying to use UBIFS on MLC flash and risking their data and products. To me, that's what's important.
This is an important patch, even if all it does is keep people from loosing data. It also changes the conversation from "I have a corrupted UBIFS device, BTW it's on MLC..." to "What can we do to get UBIFS to work on MLC".
Well, for -stable I'd suggest printk(KERN_ALERT ...) but keep the system running.
This is a bug fix.
UBI on MLC never worked. It was a bug that we ever permitted it. This is now fixed.
Yeah, well, so lets say I have a working hardware (maybe using read-only UBI on MLC), update to next stable kernel, and now kernel refuses to see the partition.
Read-only does not save you from the read-disturb issue, and you even have to take care of programming the full erase-block on some MLC NANDs, which AFAIR is not done when updating a static volume.
I have one simple question: did you ever play with MLC NANDs or are you just trolling? If you had, like Richard and I did when working on MLC support, I'm pretty sure you wouldn't play this "don't backport to stable" card.
Now, if you volunteer to add reliable MLC support, I can send you a few boards to play with. I even have a "working but not so tested PoC" here [1] if you want to finish the job, but please don't do the mistake of thinking the fix is that simple.
I'll certainly not consider this patch a bug fix.
And apparently a lot of people disagree with you on this point, and I guess all of them had problems with MLC NANDs.
Removing support for hardware that "only works by mistake" may be good idea, but maybe it is slightly too surprising for a -stable.
I wouldn't say "work by mistake" but "seems to work at first but in the end breaks", so definitely a candidate for -stable IMO.
Regards,
Boris
[1]https://github.com/bbrezillon/linux/tree/nand/mlc
Hi Boris,
On Wed, Mar 07, 2018 at 11:30:57PM +0100, Boris Brezillon wrote:
I have one simple question: did you ever play with MLC NANDs or are you just trolling? If you had, like Richard and I did when working on MLC support, I'm pretty sure you wouldn't play this "don't backport to stable" card.
Just adding my two cents here, I've always had stability issues with ubifs on NAND and I never knew what type of NAND I've had in these devices (eg: Iomega Iconnect with 256 MB NAND IIRC), so maybe this has never been relevant, maybe it has been, I don't know. However, as a stable maintainer I also know that we want to encourage people to always keep their kernels up to date with latest fixes, and that if there is the slightest risk that a loss of functionality makes people revert and stick to an older, working version, keeping their bugs forever, it's twice as worse, because : - they still run on the bug you wanted to fix - they are now exposed to all bugs fixed later.
And we all do this as users, thinking "I'll bisect and report tomorrow" and priorities change, let's be honnest. Thus I think that if you are absolutely certain that it's impossible that people are accidently using this combination, it's probably fine, but if people are using it, you're just displacing the burden on the stable team who will have to explain to each and every user complaining "my system stopped booting after an upgrade to 4.x.y". A big red alert polluting the logs and console every minute, and a pause at boot saying "your NAND, your data and all your kids photos will die soon if you don't switch to another FS" is more productive as users will be less tempted to blindly revert and will at least ask what the problem is and what their solutions are.
There's nothing more frustrating than a regression in a stable branch, even for something that was not supposed to work but did by accident.
I wouldn't say "work by mistake" but "seems to work at first but in the end breaks", so definitely a candidate for -stable IMO.
Well, removing support definitely makes the end closer and possibly even prevents the user from recovering their data. I know that data loss is terrible, but data confiscation is similar from the user's point of view.
Users don't know the technical details so they will do all things we often consider stupid or impossible, but when warned they know that the risk is on their side and they cannot put the fault at anybody anymore. It tends to work better.
Just my two cents, Willy
linux-stable-mirror@lists.linaro.org
-
Boris Brezillon -
Pavel Machek -
Willy Tarreau