LWN: Comments on "Supporting the UFS turbo-write mode"

Supporting the UFS turbo-write mode

pabs — Wed, 22 May 2019 10:54:44 +0000

That sounds a bit like open-channel SSDs:

https://en.wikipedia.org/wiki/Open-channel_SSD https://openchannelssd.readthedocs.io/en/latest/

Supporting the UFS turbo-write mode

amworsley — Wed, 22 May 2019 03:04:11 +0000

I'm not sure that Linux has a filesystem suitable for MLC or QLC flash.
As I understand it ubifs has given up supporting MLC and one presumes QLC would have even more problems.

This patch causes ubifs to refuse to handle MLC flash rather than allow people to build systems that would be unreliable (i.e. using UBIFS on top of MLC).

https://lore.kernel.org/patchwork/patch/920344

This mailing list item talks about ubihealthd (never merged into mtd-utils) which was a proposal for handling less reliable NAND.

https://linux-mtd.infradead.narkive.com/8ho9BqEp/ubi-bitr...

Happy to be updated/proven wrong :-)

Supporting the UFS turbo-write mode

sbates — Tue, 21 May 2019 13:18:47 +0000

This has been attempted several times and is, in essence what Open Channel and Lightnvm attempt to do.

The challenge is that there is a lot of secret sauce in the firmware of a modern SSD and no vendor is willing to open that up to the world. Also such a SSD would need to reveal low level details of the NAND that the NAND vendors are not willing to do either.

Supporting the UFS turbo-write mode

james — Tue, 21 May 2019 11:04:38 +0000

Most Chromebooks ship with eMMC.

Also most Windows laptops with less than 100 GB of disk space. Admittedly, that is a very price-concious market, but if UFS ever gets to similar prices to eMMC, they would switch.

And Linux runs a lot better in limited storage than Windows 10.

Supporting the UFS turbo-write mode

roblucid — Tue, 21 May 2019 07:08:37 +0000

Looking at linked to background material:

"UFS is positioned as a replacement for eMMCs and SD cards. The electrical interface for UFS uses the M-PHY,[5] developed by the MIPI Alliance, a high speed serial interface targeting 2.9 Gbit/s per lane with up-scalability to 5.8 Gbit/s per lane."

Supporting the UFS turbo-write mode

roblucid — Tue, 21 May 2019 07:06:01 +0000

How do you implement this?
Use LBA's on top of a flash drive, which ASSUMES it's formatted in vfat, treating the area used by MFT separately?
More general purpose drives, still compete and differentiate on controller & intetnal druve smarts.
Suppose a vendor co-operates, their drive has immature Linux only management code tied to the exact OS version. How do you sell that?
What you want is Open Hardware with Open Firmware for Open OSes but purchasers don't fund such development, they buy based on short term performance/convenience considerations.

Supporting the UFS turbo-write mode

roblucid — Tue, 21 May 2019 06:56:44 +0000

It would appear to be addressing a different market segment entirely, NVMe puts non-volatile storage on the PCIe lanes for v. high transfer speed minimising latency, rather than be driven by a HDD era I/O protocol.
It sounds like UFS is intended as a way to use some SLC to speed up an inexpensive flash storage device used in mobile.

Supporting the UFS turbo-write mode

marcH — Tue, 21 May 2019 03:38:47 +0000

Isn't that the exact same situation than SSHDs?

Why don't SSHDs need a "turbo mode"? Because they're more expensive so there was enough money for a complete firmware implementation?

> There are lots of unknowns, presumably devices will have different ratios of SLC to TLC, which would have an effect on what those decisions should be.

Yeah, who's in charge here? It should be either the drive or the driver but not shared across with a ridiculously poor exchange of information between the two... Maybe the UFS standard body has been infiltrated by NVMe members? :-)

> Ts'o said that these flash chips are targeting mobile devices, so if it goes slow after three months or something, the mobile-device makers will not care because the reviewers will never test them for that long.

Priceless, thanks :-)

More seriously: pretty much every such reviewer has already complained about mobile devices slowing down over time. It looks like with cheap flash memory you "got what you paid for" - even long before "turbo mode" came up. I would really love if someone performed some before/after eMMC benchmarking some day, even a non rigorous one.

> Christoph Hellwig cautioned that "I wish that were true", but there are other classes of hardware where UFS is being considered—though probably not for laptops, he conceded.

Most Chromebooks ship with eMMC.

Supporting the UFS turbo-write mode

nevyn — Tue, 21 May 2019 03:21:50 +0000

That face when your brain is old enough it thinks "Unix FS?" when you see the title "Supporting the UFS turbo-write mode" 🧐

Supporting the UFS turbo-write mode

k8to — Mon, 20 May 2019 23:34:09 +0000

I think you'll find that Linux kernel developers would be mostly OK with this state of affairs, given that the device vendors expose enough information to make reasonable decisions. However, device vendors have often proven to not be very fond of this approach.

Supporting the UFS turbo-write mode

kfox1111 — Mon, 20 May 2019 23:09:08 +0000

A flash drive is a computer. It has its own OS, and exposes the raw blocks through a complicated filesystem implementing wear leveling and other features back as a block device to the main computer with a few commands via sata/scsi.

This embedded OS typically suffers from the same problems other proprietary OS's have.
Open source OS's usually doesn't have these issues.

Why not (at least for a while):
* make the ssd's a dumb collection of blocks again
* make a linux subsystem for wear leveling the raw blocks

This would leverage the power of open source and allow the the ability to tune the api between the wear leveling subsystem and regular linux driver / block device / file system layers in order to take into account things like SLC/TLC splits, write behaviors, scheduling flushing wherever the correct place for that is, without taking into account rigid api's. The correct api's can be discovered along the way.

Perhaps once the api's have been fleshed out and work well for these sorts of things, then the logic can once again be pushed down right into the devices, but this time with an api designed not in the age of spinny disks, but for flash specifically.

Supporting the UFS turbo-write mode

jhoblitt — Mon, 20 May 2019 22:58:34 +0000

How is UFS better, faster, or cheaper than NVMe? Or is this about patent pools?