New hard disk architectures

  • Thread starter Thread starter YKhan
  • Start date Start date
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.
 
YKhan said:
Well, actually, that's one of the things they were talking
about, integrated flash on the motherboard vs. in the drive.
Click to expand...

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.
 
from the wonderful person said:
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.
Click to expand...

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.
 
It would allow an even deeper level of coma than 'Hibernation' I guess
Click to expand...

Faster than hibernate anyway.
.. you could turn the power off or pull the wall plug and still resume where
you left off.
Click to expand...

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.
Click to expand...

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

I just leave desktops on all the time and hibernate the laptop.
 
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.
Click to expand...

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...
 
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...
Click to expand...

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.
 
In comp.sys.ibm.pc.hardware.storage YKhan said:
They're talking about integrating flash with hard disks, as well as
increasing the sector size from 512 bytes to 4096 bytes.
Click to expand...
Revamping Hard Disk Architecture
http://www.extremetech.com/article2/0,1697,1901955,00.asp
Click to expand...

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
 
Arno Wagner said:
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.
Click to expand...
As to 4096 Byte sectors, I frankly do not see the point.
Click to expand...

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.
Click to expand...

Different issue.
Clustering also provides the possibility to
use larger than 512Byte as allocatioon unit.
Click to expand...
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.
Click to expand...

It isnt just one vendor.
 
Neither flash+HDD...

The issue is in saving RAM state, and the on-drive flash won't help much.
 
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.
Click to expand...

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.
 
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.
Click to expand...

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
 
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.
Click to expand...

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.
Click to expand...

.....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.
Click to expand...

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).
Click to expand...

....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...
Click to expand...

Well, M$ does seem to have a problem with that "spiral write", but
I don't think flash would help them out.
 
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.
Click to expand...

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
 
In comp.sys.ibm.pc.hardware.chips daytripper said:
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.
Click to expand...

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.
Click to expand...

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
 
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.
Click to expand...

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
 
Arno said:
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.
Click to expand...

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.
Click to expand...

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
 
Back
Top