LWN.net Logo

Future storage technologies and Linux

Future storage technologies and Linux

Posted Apr 6, 2011 20:12 UTC (Wed) by drdabbles (subscriber, #48755)
In reply to: Future storage technologies and Linux by iabervon
Parent article: Future storage technologies and Linux

When you say "easy", I think you're saying the concept is easy. The actual process of getting this to work is far from easy. Settling on an ABI and making sure it's future-proof for a hard drive that could live 10+ years in service isn't an easy thing!

What's worse, when you look at it from a manufacturer's point of view, is allowing custom firmware to be loaded to your drive. Manufacturers publish all kinds of error rates, defect rates, and other reliability metrics so enterprises can gauge how a drive will perform for a period of time. If you throw extra software into the mix, there is NO level of predictability! What happens if you aggressively park heads too often, and they mis-align or do damage? What happens if you perform complex functions for a long period of time and cause thermal issues with the CPU? These problems go on and on.

The repercussions of allowing custom firmware onto devices goes far beyond lifespan issues, too! Imagine if your hard drive's firmware crashed as much as [insert crashy OS you don't like here]! Data loss and/or corruption is a massive problem for storage devices when a manufacturer makes a mistake in firmware (Seagate has done this a couple times lately). It turns out, people expect hard drives to Just Work (tm).

I think the better alternative to creating on board software loads that do creative things is to work with manufacturers to build a generally well-rounded interface for all operating systems, and to leave the creativity up to the block and VFS layers.

One creative thing that could be done is to use the SSD portion of a hybrid drive as a large journal area, and use the filesystem's ability to journal data as well as metadata. Delay a write briefly to this area, causing the write to be a sequential write, thereby speeding up the write. When the filesystem flushes the journal, the data is committed to rotational media in the background. Obviously, the longer you delay a write, the more chance there is for data to be lost, so it's not perfect but it's a spit-balled idea.


(Log in to post comments)

Future storage technologies and Linux

Posted Apr 6, 2011 21:50 UTC (Wed) by iabervon (subscriber, #722) [Link]

If the firmware loaded to the drive by some OS corrupted data or parked the heads frequently, it wouldn't be all that different from the OS corrupting data or parking the heads itself, particularly since the firmware would only be present while that particular OS was running. I'd much rather trust that my OS implemented the filesystem right twice than trust that both my OS and my hard drive manufacturer implemented the filesystem right. Of course, it would only run the OS's firmware in the drive processor's userspace, and the drive's kernel (and ASIC portions) would take care of the important stuff.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds