Re: [PATCH] block: export SSD/non-rotational queue flag through sysfs

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2009-01-15 at 10:07 -0500, Greg Freemyer wrote:
> On Thu, Jan 15, 2009 at 12:37 AM, Tejun Heo <htejun@gmail.com> wrote:
> > Hello,
> >
> > James Bottomley wrote:
> >> I'm afraid that's pretty much marketing coolaid.  Rotational storage
> >> will dominate for the forseeable future: just do a simple back of the
> >> envelope calculation:
> >
> > Or just compare prices per byte of memory, flash and rotation disk.
> > They haven't had changed too much during last several years.
> > Secondary storage which is only slightly cheaper than the primary
> > storage doesn't have much chance of flying high and far.
> >
> > Thanks.
> >
> > --
> > tejun
> 
> Have you seen the new pricing Samsung has announced for their 3rd
> generation SSD.  It is about 1/3 of the Intel' SSD price if I recall
> correctly and the performance is approaching Intel's from what I've
> seen.

I think the point Tejun and I are trying to make is that current SSD
pricing is an artefact of the fact that there's currently a world
surplus of flash components and that today SSD production is tiny.  If
SSD production rises, the demand pressure will force flash prices back
to normal (or even above if manufacturers can charge a premium) and
you'll see SSDs priced much higher than rotational storage.

That's not to say that no-one should be buying todays cheap flash
storage ... just a warning that it can't last if SSDs become hugely
popular.

> I've been talking to the OpenHSM (Hierachical Storage Manager) team
> about their project.  They are working on getting the logic in place
> now to move data blocks from one class of storage to another while
> leaving the filesystem itself un-affected from the users perspective.
> 
> http://code.google.com/p/fscops/
> 
> They have a very long way to go with their code/project, but it is
> conceptually similar to the ext4_defrag patch that already exists.
> The big difference is the data block allocation algorithm will have to
> be totally different.
> 
> If and when that get their code done, I would love to have 500 GB of
> SSD teamed with several TB of rotational HDD and have the HSM move my
> files between fast SSD and slow rotational.  I typically know which
> datasets I will be working with heavily, so even a simple user space
> tool that would let me adjust which tier of storage my files were
> sitting on would suffice.

Right, this is the flash cache idea that's been floating around for a
while.  It's even been suggested as a way of avoiding the IDE barrier
flush penalties.  I think Seagate went as far as making hybrid drives
that were a large flash cache backed by rotational storage.

James