New hard disk architectures

[YKhan]

They're talking about integrating flash with hard disks, as well as
increasing the sector size from 512 bytes to 4096 bytes.

Revamping Hard Disk Architecture
http://www.extremetech.com/article2/0,1697,1901955,00.asp

 

[Rod Speed]

They're talking about integrating flash with hard disks,

Cant see the point myself, better on the motherboard.

 

[YKhan]

Well, actually, that's one of the things they were talking about,
integrated flash on the motherboard vs. in the drive. Also they're
figuring out whether to go with NOR or NAND. NOR would be easy to
integrate, NAND would be cheap but a little more finicky to program.

 

[Rod Speed]

Well, actually, that's one of the things they were talking
about, integrated flash on the motherboard vs. in the drive.

Yeah, I read the article. I was commenting on your subject line.

Not convinced for most desktop systems tho, even on the motherboard.

Could be useful in laptops.

 

[GSV Three Minds in a Can]

Yeah, I read the article. I was commenting on your subject line.

Not convinced for most desktop systems tho, even on the motherboard.

Could be useful in laptops.

It would allow an even deeper level of coma than 'Hibernation' I guess
... you could turn the power off or pull the wall plug and still resume
where you left off. If the speed was right (which could be arranged)
then maybe you could use it as some place to store %bloatwaredir% and
get even cold boots going PDQ.

 

[Rod Speed]

It would allow an even deeper level of coma than 'Hibernation' I guess

Faster than hibernate anyway.

.. you could turn the power off or pull the wall plug and still resume where
you left off.

And it could choose to leave the hard drive off most of the time.

If the speed was right (which could be arranged) then maybe you could use it
as some place to store %bloatwaredir% and get even cold boots going PDQ.

Yeah, that's what the article is mostly on about.

I just leave desktops on all the time and hibernate the laptop.

 

[daytripper]

It would allow an even deeper level of coma than 'Hibernation' I guess
.. you could turn the power off or pull the wall plug and still resume
where you left off.

You can do that with a five year old peecee and an even older hard drive.
Hibernate doesn't depend on any circuitry maintaining state, it's a boot-time
function that loads the current hiberfil.sys file if it is valid...

 

[Keith]

You can do that with a five year old peecee and an even older hard drive.
Hibernate doesn't depend on any circuitry maintaining state, it's a boot-time
function that loads the current hiberfil.sys file if it is valid...

THe hybernate file isn't kept up-to-date. It takes time to hybernate
(maybe even 30sec with 2GB of RAM ;-). Kick the plug out and you *won't*
go back to where you were.

 

[Arno Wagner]

They're talking about integrating flash with hard disks, as well as
increasing the sector size from 512 bytes to 4096 bytes.

Revamping Hard Disk Architecture
http://www.extremetech.com/article2/0,1697,1901955,00.asp

This has been around for some time. The flash does not really help,
unless you write very littel to disk. Personally I think SRAM
and batteries are a better choice, also because flash has relatively
low number of write cycles before it breaks. Not so bad with a disk
mapped 1:1 to flash (e.g. because it is entirely flash), but a serious
problem if a small flash has to buffer all writes to a large disk.
Maybe they are just trtying to create disks that break after 2
years or so...
Note that SRAM+battery has been around for at least a deacde in more
expensive RAID controllers, so the basic idea is old.

As to 4096 Byte sectors, I frankly do not see the point. Multi-sector
transfer stream more than 512 bytes on one go already. Clustering also
provides the possibility to use larger than 512Byte as allocatioon
unit.

I think this is mainly some HDD vendor trying to make themselves
more interesting to a public that does not really understand what
they are talking about.

Arno

 

[Rod Speed]

This has been around for some time. The flash does not really help,
unless you write very littel to disk. Personally I think SRAM
and batteries are a better choice, also because flash has relatively
low number of write cycles before it breaks. Not so bad with a disk
mapped 1:1 to flash (e.g. because it is entirely flash), but a serious
problem if a small flash has to buffer all writes to a large disk.
Maybe they are just trtying to create disks that break after 2
years or so...
Note that SRAM+battery has been around for at least a deacde in more
expensive RAID controllers, so the basic idea is old.

As to 4096 Byte sectors, I frankly do not see the point.

The point is that that allows more data to be stored on
the drive, essentially because less is wasted for headers.

Multi-sector transfer stream more than 512 bytes on one go already.

Different issue.

Clustering also provides the possibility to
use larger than 512Byte as allocatioon unit.

I think this is mainly some HDD vendor trying to make
themselves more interesting to a public that does not
really understand what they are talking about.

It isnt just one vendor.

 

[Alexander Grigoriev]

Neither flash+HDD...

The issue is in saving RAM state, and the on-drive flash won't help much.

 

[George Macdonald]

Well, actually, that's one of the things they were talking about,
integrated flash on the motherboard vs. in the drive. Also they're
figuring out whether to go with NOR or NAND. NOR would be easy to
integrate, NAND would be cheap but a little more finicky to program.

Two different initiatives though: the HDD mfrs are trying to extend the
life of rotating platter systems; Intel's Robson is a fast startup
"technology" http://www.pcworld.com/news/article/0,aid,123053,00.asp.

 

[daytripper]

THe hybernate file isn't kept up-to-date. It takes time to hybernate
(maybe even 30sec with 2GB of RAM ;-). Kick the plug out and you *won't*
go back to where you were.

Because that very hiberfil.sys *is* being updated, and until it has completed
successfully, the hiberfil.sys *is not* up to date. But that isn't the point.

The point is there is no requirement for any level of system power to maintain
state to allow a system to come back from hibernation.

Once a system has successfully created the hiberfil.sys and shut down, you can
kick the plug all you like, but when you finally get tired of that and plug it
back in and hit the power switch, the system should successfully return from
hibernation.

Thus flash (on-drive or elsewhere) really doesn't offer any additional benefit
wrt hibernation (or standby, for that matter).

Further, it's a bit dubious to believe what should be a spiral write to disk
is going to go any faster to a chunk of flash memory located on the drive...

/daytripper

 

[Keith]

Because that very hiberfil.sys *is* being updated, and until it has completed
successfully, the hiberfil.sys *is not* up to date. But that isn't the point.

But you *cannot* just turn power off or pull the plug at any time
and expect to have the filesystem in tact.

The point is there is no requirement for any level of system power to maintain
state to allow a system to come back from hibernation.

.....if it's shut down after hibernation is complete.

Once a system has successfully created the hiberfil.sys and shut down, you can
kick the plug all you like, but when you finally get tired of that and plug it
back in and hit the power switch, the system should successfully return from
hibernation.

Sure, but that's hardly the point.

Thus flash (on-drive or elsewhere) really doesn't offer any additional benefit
wrt hibernation (or standby, for that matter).

....which was my point.

Further, it's a bit dubious to believe what should be a spiral write to disk
is going to go any faster to a chunk of flash memory located on the drive...

Well, M$ does seem to have a problem with that "spiral write", but
I don't think flash would help them out.

 

[daytripper]

But you *cannot* just turn power off or pull the plug at any time
and expect to have the filesystem in tact.


....if it's shut down after hibernation is complete.


Sure, but that's hardly the point.

If you go back to the statement I'm arguing, of course this is the point.

I believe you're freely associating Hibernation with some methodology to
survive and recover from sudden loss of system power. This has not been
proposed in this thread, as the scope of any solution that doesn't include
alternate power sourcing (eg: battery) would require system-wide recovery
state being maintained, if not in "real time" at the very least as
checkpoints, which would not only degrade peak system performance to varying
degrees, but would probably be incompatible with current non-volatile
components.

Hibernation is the result of an intentional act - whether inspired by a button
push or as the result of a UPS demanding it. If you want to argue that a
system can crash in the middle of hibernation, well, fine, but that has
nothing to do with this particular discussion, which, again, is whether
maintaining state with power is required to support Hibernation...

Cheers

/daytripper

 

[Robert Redelmeier]

Because that very hiberfil.sys *is* being updated, and until it has completed
successfully, the hiberfil.sys *is not* up to date. But that isn't the point.

Why does "up to date" matter? Does it need to be within the
last 17ms of an AC cycle? For many PC purposes, a _consistant_
image for 15 seconds ago would do.

Once a system has successfully created the hiberfil.sys and shut
down, you can kick the plug all you like, but when you finally
get tired of that and plug it back in and hit the power switch,
the system should successfully return from hibernation.

Actually, I was more brutal while testing FreeBSD: I kicked
the plug towards the end of kernel compiles. In 3 out of 4
trials, the compile restarted cleanly, taking a combined 30
sec longer. Once it had to be restarted from scratch. In no
case was the filesystem damaged, thanks to Kirk McCusack's
SoftUpdates (essentially carefully ordered disk writes).

-- Robert

 

[dawg]

Wouldn't it raise the cost of a Motherboard considerably?

 

[Rod Speed]

Wouldn't it raise the cost of a Motherboard considerably?

Not really.

 

[daytripper]

Why does "up to date" matter? Does it need to be within the
last 17ms of an AC cycle? For many PC purposes, a _consistant_
image for 15 seconds ago would do.

Ok, but how much of your system's performance are you willing to give up?

Again, you're taking a "Green PC" function, primarily intended to save power
while cutting boot time, and trying to feature-creep it up to the level of
power-fail state recovery. Recovery of any type is not what Hibernate was
intended to solve, and the memory dump to disk only happens when an entry into
Hibernate is requested - there's no attempt to keep the image up to date while
you're chugging along, in the event the mains collapse.

In the realm of availability features such as you were thinking of, there are
plenty of checkpointing methods with various types of commit strategies
executed across many different transports based on all kinds of patents. What
you still end up with is a hard problem that hasn't been solved very
effectively...

Cheers

/daytripper

 

[Yousuf Khan]

This has been around for some time. The flash does not really help,
unless you write very littel to disk. Personally I think SRAM
and batteries are a better choice, also because flash has relatively
low number of write cycles before it breaks. Not so bad with a disk
mapped 1:1 to flash (e.g. because it is entirely flash), but a serious
problem if a small flash has to buffer all writes to a large disk.
Maybe they are just trtying to create disks that break after 2
years or so...
Note that SRAM+battery has been around for at least a deacde in more
expensive RAID controllers, so the basic idea is old.

I don't think they're talking about using flash in the sense of a
dynamic disk cache, but as a static disk cache, or a ramdisk in other
words. Namely, they're aiming to cache the boot sequence into the
flashdisk to speed up boot times.

As to 4096 Byte sectors, I frankly do not see the point. Multi-sector
transfer stream more than 512 bytes on one go already. Clustering also
provides the possibility to use larger than 512Byte as allocatioon
unit.

Well, they explained it in article, they're saying that the reason this
is needed is because with only 512 bytes you don't have enough bits for
error correcting code with today's big hard disks.

Yousuf Khan