| |||||||||||||
Future storage technologies and LinuxFuture storage technologies and LinuxPosted Apr 6, 2011 2:28 UTC (Wed) by neilbrown (subscriber, #359)Parent article: Future storage technologies and Linux
> What, he asked, does the Linux community want?
That's easy. We want well documented access to the low level device features. Any address-translation-layer should be optional at most.
The hybrid drive that is part SMR and part non-shingled sounds like a neat idea. But if I had one I would want to be able to address the two parts directly, and know how much and at what alignment I need to write to the SMR section.
Then we can do whatever mapping is needed in Linux, maybe in the filesystem, maybe in a virtual block device, maybe both. And different people can try out different approaches.
i.e. we want freedom (is that a surprise?).
(Log in to post comments)
Future storage technologies and Linux Posted Apr 6, 2011 13:51 UTC (Wed) by njwhite (subscriber, #51848) [Link]
> We want well documented access to the low level device features.
> Any address-translation-layer should be optional at most.
Indeed. To rely entirely on wierd vendor firmware to decide what to do with my data is to be locked in to the vendor for updates. Even very good firmware can't predict new situations which will come up. And the freedom to try new ideas and models is a great thing.
Also, to put on my paranoid hat for a moment, not having a large translation layer also reduces the surface for malicious stuff.
Future storage technologies and Linux Posted Apr 7, 2011 6:15 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] But if you write your Linux driver to bypass the processor on your high-end disk, you're almost guaranteed to have a lower-performance system than the Windows competition, because you're forcing the main CPU to do all the work.Now, if there were a way to write free firmware to run on that high-end dedicated ARM processor with 1Gb memory, that would be cool. So maybe the way to go is to start by assuming that you'll do that, then figure out what the interface should be between the host and the dedicated disk processor. Then both the FLOSS people and the proprietary people could program to that interface.
Future storage technologies and Linux Posted Apr 7, 2011 21:19 UTC (Thu) by jhhaller (subscriber, #56103) [Link]
One of the reasons the drive firmware is faster is that on startup, the drive can start figuring out where all the data is before the OS boots. The advantage is bigger for solid state drives, where the controller doesn't have to wait for the drive to spin up. If the OS controlled everything, it couldn't start reading that data until the OS got to the point of reading the data. Plus, the "native" drives couldn't be used as a boot drive, as the BIOS wouldn't know how to read it.
Future storage technologies and Linux Posted Apr 7, 2011 19:14 UTC (Thu) by eds (guest, #69511) [Link]
Every SSD in the world does far worse: data gets placed in some physical location that the host will never know, gets relocated periodically as part of wear-leveling and reclamation of partially-used flash blocks, and perhaps due to eventual ECC degradation.
Shingled HDD media, hybrid storage, and solid-state drives based on unreliable media will all force you into a situation where you will be unable to know the physical layout of your data, and you'll be at the mercy of the device firmware.
Learn to love the bomb?
Future storage technologies and Linux Posted Apr 7, 2011 20:36 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
umm, 'normal' hard drives have been transparently relocating data for the last 15 years or so, this is nothing new.
Future storage technologies and Linux Posted Apr 8, 2011 21:28 UTC (Fri) by giraffedata (subscriber, #1954) [Link] umm, 'normal' hard drives have been transparently relocating data for the last 15 years or so Hardly ever. If you assume block N is always next to N+1, your performance won't be noticeably different from optimum. I'm lost in this thread, though. In response to a comment giving a few reasons that it's better for Linux to control a drive than for a controller bundled with the drive to do it, eds writes, "Every SSD in the world does far worse." Far worse than what? I thought this might be a misplaced comment meant to respond to the issue the article raises of these new disk drives having unpredictable layout. But the unpredictable layout of SSD blocks isn't the same problem: on a disk drive, unlike an SSD, it matters a lot for speed in what physical order you access the blocks.
Future storage technologies and Linux Posted Apr 6, 2011 18:38 UTC (Wed) by cmccabe (guest, #60281) [Link]
> That's easy. We want well documented access to the low level device
> features. Any address-translation-layer should be optional at most.
Drive manufacturers could ship drives with a dual interface. The first interface would be a Windows-centric SATA interface, with a block remapping layer and the NTFS and FAT-specific hacks. The second would be a raw interface that let the OS access erase blocks (for flash) or different kinds of storage (for SMR).
The second interface would be popular with people using Linux servers (or desktops), companies building NAS devices, and writing drive diagnostic or defragmentation tools. Those markets aren't as big as the Windows desktop market, but they do exist.
It would be nice to see Red Hat, or Oracle, or some other company with the resources needed to engage with the drive manufacturers about this. Even Apple has a dog in this fight, since they would benefit from such an interface. If nobody comes forward, I think we're in danger of going down a WinModem-like path where every SSD or next-generation drive will be optimized for NTFS and Win7, and other filesystems will perform poorly.
|
|||||||||||||