Linux Storage and Filesystem Workshop, part 2

"The only real issue is that once you give raw flash to the OS and put the smarts in the OS, it'll be harder for dual-boot systems to communicate on the same media, because the likelihood that $VENDOR's Windows driver organizes the disk the way Linux does is slim to none unless $VENDOR works with the Linux community also."

Firstly, we've never had many problems working with "foreign" formats. We cope with NTFS, HFS and various bizarre crappy "Software RAID" formats, amongst other things. That includes the special on-flash formats like the NAND Flash Translation Layer used on the M-Systems DiskOnChip devices, which has been supported for about a decade. Are you suggesting that hardware vendors take Linux less seriously now than they did ten years ago, and that we'd have a harder time working out how to interoperate? Remember, documenting the on-medium format doesn't necessarily give away all the implementation details like algorithms for wear levelling, etc. — that's why M-Systems were content to give us documentation, all that time ago.

Secondly, interoperability at that level isn't a showstopper. It's nice to have, admittedly, but I'm not going to lose a lot of sleep if I can't mount my Windows or MacOS file system under Linux. It's the native functionality of the device under Linux that I care about most of the time.

Of course, I see no reason why the device vendors should be pushing their own "speshul" formats anyway — the hard drive vendors don't. But I'm not naïve enough to think that they won't try.

Imagine a world where every hard drive you buy is actually a more like a NAS. You can only talk a high-level protocol like CIFS or NFS to it; you can't access the sectors directly. Each vendor has their own proprietary file system on it internally, implemented behind closed doors by the same kind of people who write BIOSes. You have no real information about what's inside, and can't make educated decisions on which products to buy. Having made your choice you can't debug it, you can't optimise it for your own use case, you can't try to recover your data when things go wrong, and you sure as hell can't use btrfs on it. All you can do is pray to the deity of your choice, then throw the poxy thing out the window when it loses your data.

If the above paragraph leaves you in a cold sweat, it was intended to. That's the kind of dystopia I see in my head, when we talk about SSDs without direct access to the flash.

What I'd like to see is something I can get off the shelf at my local Computer Mart (or on the web) that plugs into my PC and gives me raw flash.

If a PCIe expansion socket is sufficient, several companies are now selling that. I remember IBM demonstrating last year a prototype storage server composed of a bunch of Linux systems with Fusion-IO PCI Express cards for storage. It broke some kind of record.

In that system, the flash storage still appeared as a block device, but it did it at the Linux block device interface instead of at the SCSI physical interface.

So you're saying there is innovation to be done. That means there's something for someone to monopolize with a patent.

At least with a black box, the patents are all paid for as part of acquiring the box. In contrast, when you need a patent license to run some code in your own Linux system, it usually means the code is useless."

That's a very pessimistic viewpoint. If you truly believe that the patent system is so broken and abused that it prevents all innovation, ...

But I said the opposite. I suggested someone would do the innovation. And then patent it. It is not pessimistic to expect an inventor to patent his invention; they do it all the time, even for trivial inventions.

Patents seem to be anathema to the Linux world. I thought you said patents are the reason Linux and Winmodems don't get along; I'm just trying to complete the analogy.