Flash memory in Hybrid hard drives *save* power

[Guest]

Archived from groups: alt.video.ptv.tivo (More info?)

"Jeff Rife" <wevsr@nabs.net> wrote in message
news:MPG.1cdc4712469640ca989ce2@news.nabs.net...
> Randy S. (rswittNO@SPAMgmail.com) wrote in alt.video.ptv.tivo:
>> There's a reason it's a "hybrid" drive. Flash memory ain't quite up to
>> the task on it's own yet. One day . . . .
>
> It will also only work in a notebook, where performance is usually traded
> for speed. Flash memory that handles current performance hard drive
> transfer speeds (20-40MB/sec) is *expensive*, and there is nothing that
> can match the 40-60MB/sec of high-performance drives.

Flash memory may be only 20-40 MB/sec, but it absolutely kills hard drives in
random access response time. If the flash section can provide data just long
enough for the hard drive to finish seeking, overall performance goes way up.

It doesn't help the constant large transfer scenario of a Tivo, but most
general purpose hard drive activity can benefit.

Ken

 

[Guest]

Archived from groups: alt.video.ptv.tivo (More info?)

Randy S. (rswittNO@SPAMgmail.com) wrote in alt.video.ptv.tivo:
> > But we *still* won't be able to use them in our TiVos. Unless TiVo makes
> > some massive changes to the MFS file system, the 300-350GB range is the
> > most it can handle on a single drive.
> >
>
> Really? What is the limiting factorin the MFS file system? I know the
> LBA48 addressing scales up a lot.

It's not LBA related. Whatever they did with the MFS file system, it
simply runs out of "directory entries" (for lack of the correct term) at
around 320GB.

IIRC, reports from the HR10-250 show that 300GB drives always work, 350GB
drives can work but might do weird things, and 400GB drives tend to destroy
the file system pretty quickly.

--
Jeff Rife |
| http/www.nabs.net/Cartoons/RhymesWithOrange/MailerDaemon.gif

 

[Guest]

Archived from groups: alt.video.ptv.tivo (More info?)

Ken Alverson (USENET.Ken@Alverson.net) wrote in alt.video.ptv.tivo:
> Flash memory may be only 20-40 MB/sec, but it absolutely kills hard drives in
> random access response time.

The typical 4-5 MB/sec flash memory that would probably be used doesn't get
as big an advantage. Adding $20-50 to the cost of the drive isn't a good
idea unless the power savings was *huge*.

> If the flash section can provide data just long
> enough for the hard drive to finish seeking, overall performance goes way up.

If you could just convince it to cache only certain data (the TiVo database
but not the video), this technology would be a big speed benefit to a TiVo.

But, for a general-purpose computer that has far more than 128MB available
for disk cache, it won't really help much.

--
Jeff Rife |
| http/www.nabs.net/Cartoons/Dilbert/NoWorkInternet.gif

 

[Guest]

Archived from groups: alt.video.ptv.tivo (More info?)

Jeff Rife wrote:
> Ken Alverson (USENET.Ken@Alverson.net) wrote in alt.video.ptv.tivo:
>
>>Flash memory may be only 20-40 MB/sec, but it absolutely kills hard drives in
>>random access response time.
>
>
> The typical 4-5 MB/sec flash memory that would probably be used doesn't get
> as big an advantage. Adding $20-50 to the cost of the drive isn't a good
> idea unless the power savings was *huge*.

But that won't always be the case, I'm sure Flash memory speed will
improve greatly rather quickly, as well as continue to drop in price.
It's not there yet, but the time horizon is pretty short.

>
>> If the flash section can provide data just long
>>enough for the hard drive to finish seeking, overall performance goes way up.
>
>
> If you could just convince it to cache only certain data (the TiVo database
> but not the video), this technology would be a big speed benefit to a TiVo.
>
> But, for a general-purpose computer that has far more than 128MB available
> for disk cache, it won't really help much.
>

Well, I think that's basically the idea behind Samsung's "hybrid" drive,
the 1 GB flash area is used for what it's good at, while other, more
typical data is left to the normal part. I think part of what was
mentioned is that the core of the OS could be loaded into the flash
section, making cold boots *extremely* quick, as well as enabling much
lower power "suspend" modes.

Randy S.

 

[Guest]

Archived from groups: alt.video.ptv.tivo (More info?)

Randy S. (rswittNO@SPAMgmail.com) wrote in alt.video.ptv.tivo:
> Jeff Rife wrote:
> > Ken Alverson (USENET.Ken@Alverson.net) wrote in alt.video.ptv.tivo:
> >
> >>Flash memory may be only 20-40 MB/sec, but it absolutely kills hard drives in
> >>random access response time.
> >
> >
> > The typical 4-5 MB/sec flash memory that would probably be used doesn't get
> > as big an advantage. Adding $20-50 to the cost of the drive isn't a good
> > idea unless the power savings was *huge*.
>
> But that won't always be the case, I'm sure Flash memory speed will
> improve greatly rather quickly, as well as continue to drop in price.
> It's not there yet, but the time horizon is pretty short.

Right, but in the same time, drive transfer rates will also increase.
The "perpendicular" technology claims a doubling in bit density, which
means a doubling in transfer rate for the same RPM drive (all else being
equal).

It might catch up, but only if flash memory needs those speeds. Right
now, 20 MB/sec is enough for what flash is typically used for. Spending
money to research increasing the speed won't do anything since the
volume applications won't benefit from the higher speeds.

> Well, I think that's basically the idea behind Samsung's "hybrid" drive,
> the 1 GB flash area is used for what it's good at, while other, more
> typical data is left to the normal part.

That's all well and good if it really was 1GB, but it's one gigaBIT, which
is only 128MB.

> I think part of what was
> mentioned is that the core of the OS could be loaded into the flash
> section, making cold boots *extremely* quick, as well as enabling much
> lower power "suspend" modes.

Combine the two and you're right. It won't decrease cold boot time
significantly because the majority of time in a cold boot for Windows XP
(the typical OS) is taken in the BIOS and the OS actually executing
code to hunt down hardware, etc.

And, the "hibernate" mode of Win2K and beyond is about as low power as
you can get, but it's a relatively slow startup if you have a lot of RAM
in use.

But, with flash, you can have a fast return from a very low power
hibernation. This technology *could* be used in a DVR that didn't need
to buffer live TV.

--
Jeff Rife | "What kind of universe is this where a man can't
| love his fake wife's mother's best friend?"
|
| -- Ned Dorsey, "Ned and Stacey"

 

[Guest]

Archived from groups: alt.video.ptv.tivo (More info?)

>>Well, I think that's basically the idea behind Samsung's "hybrid" drive,
>>the 1 GB flash area is used for what it's good at, while other, more
>>typical data is left to the normal part.
>
>
> That's all well and good if it really was 1GB, but it's one gigaBIT, which
> is only 128MB.

Whoops, I must've misread that! Yes that changes things immensely!

>
>> I think part of what was
>>mentioned is that the core of the OS could be loaded into the flash
>>section, making cold boots *extremely* quick, as well as enabling much
>>lower power "suspend" modes.
>
>
> Combine the two and you're right. It won't decrease cold boot time
> significantly because the majority of time in a cold boot for Windows XP
> (the typical OS) is taken in the BIOS and the OS actually executing
> code to hunt down hardware, etc.
>
> And, the "hibernate" mode of Win2K and beyond is about as low power as
> you can get, but it's a relatively slow startup if you have a lot of RAM
> in use.

I was differentiating "suspend" (where the computer maintains a low
power state and maintains power to the RAM) from "hibernate" (where the
computer actually turns off, and the RAM state is written to disk then
reloaded into RAM on startup). Which I think leads into your next
statement:

>
> But, with flash, you can have a fast return from a very low power
> hibernation. This technology *could* be used in a DVR that didn't need
> to buffer live TV.
>

;-) Interesting stuff. I don't disagree with anything you said, but I
think I see rotating disk technology leading into an area of diminishing
returns (I'd say we're either just getting into the initial flattening
of the curve or not quite there yet) whereas solid state memory methods
are just gather steam (we're probably just bast the initial "knee"
upwards). At some point solid state memory will likely surpass rotating
devices, but it'll be a while (10 yrs?) yet before it reaches general
use for large mass storage, and of course there will be applications for
rotating media well beyond that.

Rady S.

 

[Guest]

Archived from groups: alt.video.ptv.tivo (More info?)

"Jeff Rife" <wevsr@nabs.net> wrote in message
news:MPG.1cdc821673d3ffac989ce6@news.nabs.net...
> Ken Alverson (USENET.Ken@Alverson.net) wrote in alt.video.ptv.tivo:
>> Flash memory may be only 20-40 MB/sec, but it absolutely kills hard drives
>> in
>> random access response time.
>
> The typical 4-5 MB/sec flash memory that would probably be used doesn't get
> as big an advantage. Adding $20-50 to the cost of the drive isn't a good
> idea unless the power savings was *huge*.

In the laptop scenario, the power savings /are/ huge - with a normal system
memory cache, you can't hold onto write data for very long because if you were
to lose power or crash, that data would be gone. With the flash based cache,
you can delay the actual write indefinitely - if the system goes down, the
cached data isn't lost.

In their demos, they showed data that a laptop under "typical usage" wrote
less than 128 MB in a 10 minute period of time. With a flash based cache, the
laptop could have the hard drive turned off for that entire time.

Ken

 

[Guest]

Archived from groups: alt.video.ptv.tivo (More info?)

"Jeff Rife" <wevsr@nabs.net> wrote in message
news:MPG.1cdd922e3d869052989cea@news.nabs.net...
> Ken Alverson (USENET.Ken@Alverson.net) wrote in alt.video.ptv.tivo:
>> In the laptop scenario, the power savings /are/ huge - with a normal system
>> memory cache, you can't hold onto write data for very long because if you
>> were
>> to lose power or crash, that data would be gone. With the flash based
>> cache,
>> you can delay the actual write indefinitely - if the system goes down, the
>> cached data isn't lost.
>
> This is just just delaying the issue.

It's not. When you write to the flash, it is just as good as writing to the
drive. In fact, it is less of an issue, because the the RAM cache can be
flushed to the flash cache even more eagerly than it can the disk.

Flash is non-volatile, meaning if you crash or lose power, the data is still
there when the system is brought back up. There's always an issue if your
system goes down while data is in the memory cache, but that doesn't become
any more of an issue with a hybrid drive.

>> In their demos, they showed data that a laptop under "typical usage" wrote
>> less than 128 MB in a 10 minute period of time. With a flash based cache,
>> the
>> laptop could have the hard drive turned off for that entire time.
>
> ...and when that 129th MB needed to be written out, and power died, you're
> even *more* screwed than if you had no flash memory in the hard drive,
> because the drive is spun down and takes even longer to come back up, so
> you might even be more likely to lose data.

The flash cache becoming full is not a surprise event. It would be entirely
reasonable for the operating system to notice the cache was 90% full (or 75%
full, or whatever), spin up the drive, flush everything, and resume normal
operation. At no time would the RAM cache be waiting on the flash cache to
flush, because there would always be enough free flash cache to cover the time
it takes the hard drive to spin up.

Ken

 

[Guest]

Archived from groups: alt.video.ptv.tivo (More info?)

Ken Alverson (USENET.Ken@Alverson.net) wrote in alt.video.ptv.tivo:
> > This is just just delaying the issue.
>
> It's not. When you write to the flash, it is just as good as writing to the
> drive. In fact, it is less of an issue, because the the RAM cache can be
> flushed to the flash cache even more eagerly than it can the disk.

It's still going to take time to spin up the drive for that 129th MB, and
during that time, you can lose it and anything else in RAM that was waiting
for the disk to spin up so that the flash could be flushed to disk. If
that 129th MB happened to be the "index" to the other 128MB, then you have
effectively lost it all anyway.

With a drive that is always spinning and no flash in the picture, you would
be slightly less likely to run into this situation, so the flash would
actually make things less safe.

> The flash cache becoming full is not a surprise event.

That's definitely not true. It's easy to suddenly burst out a few hundred
MB, like printing a PDF file (the disk spool can be huge for these, even
when the file is small).

> It would be entirely
> reasonable for the operating system to notice the cache was 90% full (or 75%
> full, or whatever), spin up the drive, flush everything, and resume normal
> operation.

The OS shouldn't be involved at all...the drive should do everything in
hardware, but that's another issue.

But, if you always flush at 90% full (or 75% full, or whatever), then you
waste a big chunk of expensive memory and still gain very little safety.
There's no doubt these hybrid drives will save some power, but they won't
increase safety significantly...if that was true, there would have been
add-in flash cache devices sold already.

--
Jeff Rife | "I feel the need...the need for
| expeditious velocity"
|
| -- Brain

 

[Guest]

Archived from groups: alt.video.ptv.tivo (More info?)

"Jeff Rife" <wevsr@nabs.net> wrote in message
news:MPG.1ce0a8bdfc34ac14989cf7@news.nabs.net...
>
> It's still going to take time to spin up the drive for that 129th MB, and
> during that time, you can lose it and anything else in RAM that was waiting
> for the disk to spin up so that the flash could be flushed to disk. If
> that 129th MB happened to be the "index" to the other 128MB, then you have
> effectively lost it all anyway.

Which is no different than if your entire cache was RAM based, except that the
likelyhood is that your RAM cache will have more in it, since you can't flush
as eagerly.

> With a drive that is always spinning and no flash in the picture, you would
> be slightly less likely to run into this situation, so the flash would
> actually make things less safe.

Even in desktop machines, hard drives are regularly spun down. And you are
still faced with the fact that it takes time to seek the hard drive (not as
much as spinning one up, but much more than writing to random access
non-volatile storage).

Neither case is "safe". The flash cache does increase the likelyhood that the
RAM write cache is empty, though.

>> The flash cache becoming full is not a surprise event.
>
> That's definitely not true. It's easy to suddenly burst out a few hundred
> MB, like printing a PDF file (the disk spool can be huge for these, even
> when the file is small).

In which case the process would be waiting on throughput, cache or no cache.
The flash cache can still begin writing while the hard drive is spinning up.

> The OS shouldn't be involved at all...the drive should do everything in
> hardware, but that's another issue.

Why? If the OS has more information than the hardware, it might as well be
put to good use. It would be great if the hardware could automagically divine
the best course of action, but that's asking a lot given how little
information it has to work off of.

I'm not saying the OS would have to completely manage the cache - the hardware
could do a lot of the grunt work, but for best performance, the OS would need
to at least supply hints about the operating environment.

Another point for performance is write reordering. AFAIK, a standard RAM
cache cannot reorder writes, because if something were to go wrong, you would
have nonsense data (instead of good data that was just cut off). In the case
of a flash cache, the writes must be made to the cache in sequential order,
however they could be flushed to the disk in any arbitrary order, allowing the
hardware to optimize the amount of seeking it has to do.

Ken

 

[Guest]

Archived from groups: alt.video.ptv.tivo (More info?)

"Jeff Rife" <wevsr@nabs.net> wrote in message
news:MPG.1ce2d607998ca993989d07@news.nabs.net...
>
>> In the
>> case
>> of a flash cache, the writes must be made to the cache in sequential order,
>> however they could be flushed to the disk in any arbitrary order, allowing
>> the
>> hardware to optimize the amount of seeking it has to do.
>
> That seems to be something the hard drive can do, too. NCQ SATA drives and
> SCSI drives have been re-ordering writes for a while now, and the OS
> doesn't need to know about it.

I've heard of reordering reads but not reordering writes. Perhaps this is
happening today, but I don't know how they would do it without risking serious
corruption in the face of a fault. The drive would have to keep a backup
power supply long enough to let it flush enough writes to achieve a coherent
(if incomplete) state before it turned off. (I guess drives already do keep a
little bit of spare power on hand so they can park the heads if there is a
surprise loss of power, but it would take a lot more power to let the drive
keep writing for a period of time.

Ken

 

[Guest]

Archived from groups: alt.video.ptv.tivo (More info?)

Ken Alverson (USENET.Ken@Alverson.net) wrote in alt.video.ptv.tivo:
> I've heard of reordering reads but not reordering writes. Perhaps this is
> happening today, but I don't know how they would do it without risking serious
> corruption in the face of a fault.

It's not really a serious issue.

If the head is moving from track 0 to track 1000 (where it has a pending
write), if the drive gets a write command for track 500 before the head
reaches there, it's not that much time to stop at 500 and write and then
move on. Depending on the actual seek stats, the two writes might actually
complete faster than if you do them in the order they came in.

Another reason it's not an issue is the OS does *not* get a "that data
has really been flushed to disk" until it really has. So, the chances of
corrupting data are the same as without re-ordering the writes. Since this
isn't a "delayed write" scenario (the writes take place in order unless it
would be faster to do it out of order), it shouldn't make any difference.

It might make a small difference for some database apps, but generally it
won't lead to corruption that can't be fixed...it will only cause the last
couple of writes to be bad, which is exactly what would happen with any
command queueing system when the power fails.

--
Jeff Rife |
| http/www.nabs.net/Cartoons/TractorBeam.jpg