| |||||||||||||
Future storage technologies and LinuxFuture storage technologies and LinuxPosted Apr 6, 2011 11:51 UTC (Wed) by NAR (subscriber, #1313)Parent article: Future storage technologies and Linux relatively easy for the drive to look at the partition table and figure out what kinds of filesystem(s) it is dealing with Is it? I mean the drive is manufactured in 2012 and even if it can look at the partition table and see that there's btrfs in there, when the drive is actually used in 2017, the btrfs of 2017 could behave significantly different to the btrfs of 2012...
(Log in to post comments)
Future storage technologies and Linux Posted Apr 6, 2011 14:14 UTC (Wed) by clugstj (subscriber, #4020) [Link]
This is easily the worst idea I've seen lately. I realize that the drive manufacturers are stuck interfacing w/ Microsoft, but guessing about how to handle the data is really a bad idea.
Future storage technologies and Linux Posted Apr 6, 2011 15:48 UTC (Wed) by foom (subscriber, #14868) [Link]
SSDs do that already for NTFS... It will wait until the disk is idle for a while, then parse the partition table, and then the actual filesystem on the partition itself, to find out which blocks are no longer pointed to by any files. And then, it will erase those blocks. That seems like a really really bad idea to me, but then, nobody asked me.
All this, just so that the OS doesn't need to support TRIM...
Future storage technologies and Linux Posted Apr 7, 2011 19:18 UTC (Thu) by eds (guest, #69511) [Link]
Can you link to some place with evidence of this? (Drives parsing filesystems to auto-trim blocks)
Future storage technologies and Linux Posted Apr 8, 2011 1:30 UTC (Fri) by foom (subscriber, #14868) [Link]
It was from a paper exploring the data forensics ramifications. This one, I think:
http://www.jdfsl.org/subscriptions/JDFSL-V5N3-Bell.pdf
Quick google search also finds:
http://www.pcper.com/comments.php?nid=7488
Future storage technologies and Linux Posted Apr 6, 2011 16:43 UTC (Wed) by iabervon (subscriber, #722) [Link]
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.
Future storage technologies and Linux 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.
|
|||||||||||||