Easy: the host OS installs the ARM build of btrfs-tools on the drive's userspace at boot time. That is, have some optional, per-partition firmware with a stable, standardized ABI that filesystem authors can write; without the firmware, the drive doesn't try to do anything clever specific to the filesystem. The filesystem-specific bits could probably even take care of reordering writes, since they could have access to both the physical locations of all of the sectors and the ordering requirements for filesystem consistency. Many things suddenly get easier if you can count on your device having CPU cores with a standard ISA, so that you can run some software on it instead of on the other side of the ATA bus.
Posted Apr 6, 2011 20:12 UTC (Wed) by drdabbles (subscriber, #48755)
[Link]
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.
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.