Whither "Hybrid" Disk Drives?
Jon Forrest
drive that combines a regular disk with some amount
of flash memory in the same package. (See
http://www.extremetech.com/article2/0,1697,1901955,00.asp)
for a presentation of this idea.
Except for speeding up booting and resuming,
I don't see why this is better than just adding
more system RAM memory, especially in OSs like
Windows and *nix where memory not needed for
processes is used as a disk cache.
The article mentions reducing the amount of time
a disk needs to spin, in order to reduce power conception,
but couldn't this be done just as easily by keeping data
in the OS cache? (I do recognize that flash memory
keeps its contents when the power goes off, but this
doesn't appear to me the major selling point of
hybrid disks in the articles I've seen).
The key issue I see is whether the OS or the disk controller
has a better conception of what to cache. Plus, what
happens, in worse case, if their conceptions conflict?
It's easy to imagine a case where the same data is
cached in both the OS cache and the on-disk cache.
Maybe a smart disk driver can prevent this from happening
but this whole approach seems anti-intuitive to poor me.
Where's the beef?
Jon Forrest
Casper H.S. Dik
>The key issue I see is whether the OS or the disk controller
>has a better conception of what to cache. Plus, what
>happens, in worse case, if their conceptions conflict?
>It's easy to imagine a case where the same data is
>cached in both the OS cache and the on-disk cache.
>Maybe a smart disk driver can prevent this from happening
>but this whole approach seems anti-intuitive to poor me.
The main advantage is that a disk-flash cache can cache
writes with impunity; a OS cache cannot.
I'm not sure how this will help with faster booting unless you
fix a piece of the cache as "boot memory" which will make
it less effective in saving power.
(Considering that disks can easily deliver 60MB/s faster booting
can easily be achieved by making sure that the boot memory is
a sequential blob on disk so the amount needed to boot can
be delivered in a handful of seconds)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Ketil Malde
> Where's the beef?
I guess MS has an OS they want to sell. That aside:
Jon Forrest <for...@ce.berkeley.edu> writes:
> Microsoft is making a big deal about a new kind of disk
> drive that combines a regular disk with some amount
> of flash memory in the same package. (See
> http://www.extremetech.com/article2/0,1697,1901955,00.asp)
> for a presentation of this idea.
> Except for speeding up booting and resuming,
As Casper points out, flash isn't much better - and perhaps worse? -
than the disk for transfer. Current OS'es seem to use a lot of time
to resume, (populating 1Gb should only take 20 seconds or so, but
seems to take a lot longer in practice), which I presume is due to the
stored state being fragmented on the disk - since flash eliminates
seek times, perhaps the idea is just to avoid fixing the OS in this
regard?
> I don't see why this is better than just adding
> more system RAM memory
And/or more regular on-disk cache?
As flash is becoming cheaper than RAM, and you don't need outrageous
bandwidth anyway, perhaps this is just a way to increase on-disk cache
cheaply?
> The article mentions reducing the amount of time
> a disk needs to spin, in order to reduce power conception,
> but couldn't this be done just as easily by keeping data
> in the OS cache? (I do recognize that flash memory
> keeps its contents when the power goes off, but this
> doesn't appear to me the major selling point of
> hybrid disks in the articles I've seen).
If we're talking about laptops, they already have a battery, too.
Perhaps some applications really need to write synchronously to disk
(mount without noatime), and this is a way to fix that?
> The key issue I see is whether the OS or the disk controller
> has a better conception of what to cache.
Another option is to add a separate nvram disk to the system. Flash
these days seems to be cheaper than ... well, just about anything
else, really. How could an OS make efficient use of a GB or two of
'system flash'?
-k
--
If I haven't seen further, it is by standing in the footprints of giants
Stephen Fuld
"Jon Forrest" <for...@ce.berkeley.edu> wrote in message
news:efu8i2$2s2u$1...@agate.berkeley.edu...
> Microsoft is making a big deal about a new kind of disk
> drive that combines a regular disk with some amount
> of flash memory in the same package. (See
> http://www.extremetech.com/article2/0,1697,1901955,00.asp)
> for a presentation of this idea.
>
> Except for speeding up booting and resuming,
> I don't see why this is better than just adding
> more system RAM memory, especially in OSs like
> Windows and *nix where memory not needed for
> processes is used as a disk cache.
>
> The article mentions reducing the amount of time
> a disk needs to spin, in order to reduce power conception,
> but couldn't this be done just as easily by keeping data
> in the OS cache? (I do recognize that flash memory
> keeps its contents when the power goes off, but this
> doesn't appear to me the major selling point of
> hybrid disks in the articles I've seen).
Think laptops, where battery life is a significant selling point. Having
the disk spin less means less drain on the battery, hence longer battery
life. That is the main purpose of the feature.
--
- Stephen Fuld
e-mail address disguised to prevent spam
Jon Forrest
> Think laptops, where battery life is a significant selling point. Having
> the disk spin less means less drain on the battery, hence longer battery
> life. That is the main purpose of the feature.
I thought I had mentioned this in my original posting
Again, if the goal is to reduce the amount of time a disk spins,
what difference does it make if the cache is on the disk
as opposed to on the motherboard? In either case, I/Os will still
be avoided.
Jon
Stephen Sprunk
news:egd598p...@polarvier.ii.uib.no...
> As Casper points out, flash isn't much better - and perhaps worse? -
> than the disk for transfer.
Sequential read and writes are slower, but the zero seek time gives
flash a phenomenal advantage for non-sequential reads.
> Current OS'es seem to use a lot of time to resume, (populating 1Gb
> should only take 20 seconds or so, but seems to take a lot longer in
> practice), which I presume is due to the stored state being fragmented
> on the disk - since flash eliminates seek times, perhaps the idea is
> just
> to avoid fixing the OS in this regard?
Restoring a hiberating PC is indeed faster with flash, but the real win
comes in normal boot times. I just read a review the other day of a
36GB ATA flash drive, and the system booted in under half the time that
it did with a conventional disk. That's big.
The flash drive also stomped the best rotating drive on some workloads
(e.g. web server), and it beat the merely "average" drives on nearly
every test.
> As flash is becoming cheaper than RAM, and you don't need outrageous
> bandwidth anyway, perhaps this is just a way to increase on-disk cache
> cheaply?
The idea behind this is that flash can be an intermediate cache layer
between RAM and the HD. They're even trying to push USB flash drives as
cache devices.
Personally, I'd invest in more RAM before I'd add a flash cache, but
perhaps that's just general resistance to any "great idea" MS comes up
with.
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com
Rick Jones
With flash I suppose the flush can be "whenever" whereas if one wants
to power-down the host, cache in RAM would need to be flushed. Also,
which draws more power - RAM in the host or flash in the pan/disc?
rick jones
--
Process shall set you free from the need for rational thought.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
Stephen Fuld
"Rick Jones" <rick....@hp.com> wrote in message
news:llTUg.668$Eq3...@news.cpqcorp.net...
> Jon Forrest <for...@ce.berkeley.edu> wrote:
>> Stephen Fuld wrote:
>>> Think laptops, where battery life is a significant selling point.
>>> Having the disk spin less means less drain on the battery, hence
>>> longer battery life. That is the main purpose of the feature.
>
>> I thought I had mentioned this in my original posting
>
>> Again, if the goal is to reduce the amount of time a disk spins,
>> what difference does it make if the cache is on the disk
>> as opposed to on the motherboard? In either case, I/Os will still
>> be avoided.
If you are talking RAM on the motherboard, then the difference is the
non-volatility. This is important when powering up for a reboot. Any data
stored in the RAM on the motherboard would have been lost and must be
reloaded so you must power up the disk to do that. If you are talking flash
on the motherboard as opposed to the disk, there is the issue of not having
the OS spend cycles manageing the cache, and I would guess that Seagate went
to Microsoft and said "we could do this, let's work together" but no laptop
motherboard manufacturer did so. Business. :-)
Tim Bradshaw
> With flash I suppose the flush can be "whenever" whereas if one wants
> to power-down the host, cache in RAM would need to be flushed. Also,
> which draws more power - RAM in the host or flash in the pan/disc?
Well, flash has (or can have, since it's nonvolatile) zero power
requirements if it is not being read or written...
--tim
Bill Todd
> Microsoft is making a big deal about a new kind of disk
> drive that combines a regular disk with some amount
> of flash memory in the same package. (See
> http://www.extremetech.com/article2/0,1697,1901955,00.asp)
> for a presentation of this idea.
>
> Except for speeding up booting and resuming,
As has been observed by others, there's no reason why such bulk-transfer
activities should take longer from disk than from flash - as long as
they've been optimized to execute from the disk in streaming sequential
fashion (which unfortunately does not usually seem to have been done in
current Windows environments - and perhaps others as well, FAIK - so the
flash becomes a potentially useful feature only due to the uncorrected
deficiencies of the OS).
> I don't see why this is better than just adding
> more system RAM memory, especially in OSs like
> Windows and *nix where memory not needed for
> processes is used as a disk cache.
>
> The article mentions reducing the amount of time
> a disk needs to spin, in order to reduce power conception,
> but couldn't this be done just as easily by keeping data
> in the OS cache? (I do recognize that flash memory
> keeps its contents when the power goes off, but this
> doesn't appear to me the major selling point of
> hybrid disks in the articles I've seen).
But it's *related to* the major selling point, which is that spinning up
the disk becomes a rare occurrence, hence saves significant power on a
laptop.
Laptop activities tend to save data to the disk fairly often, and the
fact that the drive may have its write-back cache enabled does not keep
it from spinning up each time (if it had been spun down - and with the
large amounts of system RAM laptops sport these days it likely otherwise
could have been), because the write-back cache is destaged fairly
immediately (unless the disk is otherwise busy) under the assumption
that if an application deliberately wrote to it it probably had good
reason for wanting that data to be persistent (otherwise, it would still
be sitting in the system's RAM write-back cache area).
Place a NV flash cache in front of the disk and it need be destaged -
well, never, unless its dirty contents overflows the area alloted for it
(and the kinds of things that tend to be saved to disk on a laptop tend
to be smallish, so that shouldn't happen often).
My main reservations about such behavior would center around whether
flash memory has reliability - especially when frequently updated in
small increments - comparable to (or better than) data on the disk
platters: if not, such write-back policies would compromise mean time
to data loss, but the average laptop user may not worry much about such
issues (though if the drive manufacturers want to convince enterprise
users that this is a great way to obtain cheap NV write-back cache in
their environments, they will have to be *very* convincing on this point).
- bill
Ketil Malde
> Restoring a hiberating PC is indeed faster with flash,
An iPAQ with Linux can apparently suspend to RAM and resume in 10ms,
and the OLTP laptop hopes to get close to that, if I interpret the
article correctly.
I guess the context here was suspend to disk, so perhaps it isn't
terribly relevant, but I thought I'd mention it anyway. The URL is
http://www.olpcnews.com/software/operating_system/speedy_olpc_suspend.html
Casper H.S. Dik
>An iPAQ with Linux can apparently suspend to RAM and resume in 10ms,
>and the OLTP laptop hopes to get close to that, if I interpret the
>article correctly.
Big deal; suspend to RAM is easy and requires powered RAM.
Suspend to disk is harder as you effectively have to recover from
a hardware power-cycle.
JJ
Stephen Sprunk wrote:
> "Ketil Malde" <ketil...@ii.uib.no> wrote in message
> news:egd598p...@polarvier.ii.uib.no...
> > As Casper points out, flash isn't much better - and perhaps worse? -
> > than the disk for transfer.
>
> Sequential read and writes are slower, but the zero seek time gives
> flash a phenomenal advantage for non-sequential reads.
>
Atleast until recently, Flash has been sort of a throwaway thing for
keychains ie 4x256MB for $20 or so, but the sizes are now ramping up so
fast that speed or lack of became obvious, it had to be fixed. 1MB/s to
10MB/s was good but we want more, to the limit of the connection
please!.
I was told recently by one vendor of Flash Drives and USB Flash sticks
(Apacer) that all devices will be hitting 30MB/sec pretty soon, and are
available already (I haven't seen those yet). They had them in the
booth, everyone is using Samsung too. So far we have seen the Toms?
article on the 30GB 30MB/s sub 2.5" drive but the same is likely to
happen with pen drives just much smaller cheaper. Personally I can't
wait till 30MB/s is the norm then maybe run mostly off that, leave the
spinning media for media files and backing the Flash drive.
> > Current OS'es seem to use a lot of time to resume, (populating 1Gb
> > should only take 20 seconds or so, but seems to take a lot longer in
> > practice), which I presume is due to the stored state being fragmented
> > on the disk - since flash eliminates seek times, perhaps the idea is
> > just
> > to avoid fixing the OS in this regard?
>
> Restoring a hiberating PC is indeed faster with flash, but the real win
> comes in normal boot times. I just read a review the other day of a
> 36GB ATA flash drive, and the system booted in under half the time that
> it did with a conventional disk. That's big.
>
> The flash drive also stomped the best rotating drive on some workloads
> (e.g. web server), and it beat the merely "average" drives on nearly
> every test.
>
The ability to reload quickly seems to be poorly done in most current
OS software and I would hope one day that Flash will take away all
excuses the software guys put up for slow boot times. SInce most of the
DRAM doesn't have to be reloaded, it should only take a few secs max to
reload working OS. Bloatware like Firefox seems to use way more ram
than this OS here.
> > As flash is becoming cheaper than RAM, and you don't need outrageous
> > bandwidth anyway, perhaps this is just a way to increase on-disk cache
> > cheaply?
>
> The idea behind this is that flash can be an intermediate cache layer
> between RAM and the HD. They're even trying to push USB flash drives as
> cache devices.
>
> Personally, I'd invest in more RAM before I'd add a flash cache, but
> perhaps that's just general resistance to any "great idea" MS comes up
> with.
>
It seems for the longest time since the 80s NV storage, eprom, eeprom
and early Flash was way more expensive than DRAM per bit and that
lasted till the mass arrival of digital cameras and MP3 players which
demanded flash card or tiny spinning media. That allows flash to be on
a much faster density growth track than DRAM even from the same vendor.
I get the impression that 16Gbit flash chips are in same $ ballpark as
1GB DRAM parts so flash has won for now, flash prices plumet while DRAM
appears to head back up again.
John Jakson
Anton Ertl
>Place a NV flash cache in front of the disk and it need be destaged -
>well, never, unless its dirty contents overflows the area alloted for it
>(and the kinds of things that tend to be saved to disk on a laptop tend
>to be smallish, so that shouldn't happen often).
I would expect that the disk has to spin up more often for reading
stuff that is not yet in RAM, and then the writes can be destaged, so
spinning up for writing should be extremely rare.
>My main reservations about such behavior would center around whether
>flash memory has reliability - especially when frequently updated in
>small increments
Any reason to think that this is not the case? If you are thinking
about parts of the flash failing to be writable because of too many
writes, that should be recognizable by reading after writing, and the
part would be marked as unusable. Also, I can think of a number of
reasons that make such events rather rare.
Or are you thinking about the flash memory losing the contents
afterwards; that would be a problem.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Bill Todd
> Bill Todd <bill...@metrocast.net> writes:
>> Place a NV flash cache in front of the disk and it need be destaged -
>> well, never, unless its dirty contents overflows the area alloted for it
>> (and the kinds of things that tend to be saved to disk on a laptop tend
>> to be smallish, so that shouldn't happen often).
>
> I would expect that the disk has to spin up more often for reading
> stuff that is not yet in RAM,
I question that, with laptop RAM complements rapidly approaching 1 GB
theses days: typical use should result in declining disk-read rates
over time as less and less cannot be found in the system RAM.
Then again, I tend to save changes on a laptop as frequently as I do on
my desktop - in perhaps both cases an increasingly obsolete habit, given
my desktop UPS and the laptop's battery plus the improving stability of
Windows (not that my family benefits much from the last, since we still
use Win98 for applications that support it: it's fast enough, stable
enough, and behind the router and local firewalls secure enough that
there's just no compelling reason to move).
> and then the writes can be destaged,
Only if the disk is willing to wait a while to destage dirty data in its
write cache - which it really shouldn't be, since that decision is the
job of the OS-level write-back caching mechanism.
I.e., once the OS thinks it's time to write data to disk (e.g., because
a user explicitly 'saved' it), the disk should get it onto its platters
as soon as is consistent with short-term performance optimization goals
(such as reordering it or, in the case of drives that don't support
large sequential transfers, aggregating it) rather than second-guess
higher-level software as to how important making it persistent may be.
so
> spinning up for writing should be extremely rare.
Only if typical use patterns differ significantly from what I've assumed
above - which they well may, but I'd want to see actual evidence of that.
>
>> My main reservations about such behavior would center around whether
>> flash memory has reliability - especially when frequently updated in
>> small increments
>
> Any reason to think that this is not the case?
My impression is that the probability of data loss from UPS-backed
conventional ECC RAM may be somewhat higher than that of data loss from
a disk (at least if one ignores whole-disk failure, which is appropriate
in this situation), but I could be mistaken or if not flash might differ
in that respect.
If you are thinking
> about parts of the flash failing to be writable because of too many
> writes,
That was what I was referring to in the 'updated in small increments'
portion.
> that should be recognizable by reading after writing,
It *should* be, but is this actually done?
and the
> part would be marked as unusable. Also, I can think of a number of
> reasons that make such events rather rare.
They need to be 'rather rare' in comparison to other modes of disk data
loss - which themselves are quite rare.
>
> Or are you thinking about the flash memory losing the contents
> afterwards; that would be a problem.
I'm not at all familiar with flash failure modes, which is why I phrased
my reservations conditionally.
- bill
Anton Ertl
>Anton Ertl wrote:
>> Bill Todd <bill...@metrocast.net> writes:
>>> Place a NV flash cache in front of the disk and it need be destaged -
>>> well, never, unless its dirty contents overflows the area alloted for it
>>> (and the kinds of things that tend to be saved to disk on a laptop tend
>>> to be smallish, so that shouldn't happen often).
>>
>> I would expect that the disk has to spin up more often for reading
>> stuff that is not yet in RAM,
>
>I question that, with laptop RAM complements rapidly approaching 1 GB
>theses days: typical use should result in declining disk-read rates
>over time as less and less cannot be found in the system RAM.
>
>Then again, I tend to save changes on a laptop as frequently as I do on
>my desktop
So how long does that take to fill a, say 128MB flash buffer?
>> and then the writes can be destaged,
>
>Only if the disk is willing to wait a while to destage dirty data in its
>write cache - which it really shouldn't be, since that decision is the
>job of the OS-level write-back caching mechanism.
The OS has already passed the stuff to the drive, and does not know
and should not care whether it is on the rotating or the flash medium.
The destaging I referred to is a purely drive-internal operation.
So, once the drive has satisfied the read requests that caused it to
spin up, and while it waits the, say, 30s period for any more read
requests before it spins down, it can write the stuff back from the
flash to the rotating medium.
>I.e., once the OS thinks it's time to write data to disk (e.g., because
>a user explicitly 'saved' it), the disk should get it onto its platters
>as soon as is consistent with short-term performance optimization goals
>(such as reordering it or, in the case of drives that don't support
>large sequential transfers, aggregating it) rather than second-guess
>higher-level software as to how important making it persistent may be.
If it's in flash, it is persistent.
>>> My main reservations about such behavior would center around whether
>>> flash memory has reliability - especially when frequently updated in
>>> small increments
>>
>> Any reason to think that this is not the case?
>
>My impression is that the probability of data loss from UPS-backed
>conventional ECC RAM may be somewhat higher than that of data loss from
>a disk (at least if one ignores whole-disk failure, which is appropriate
>in this situation), but I could be mistaken or if not flash might differ
>in that respect.
Certainly. Flash does not need a UPS in order to keep its contents,
so one less source of unreliability.
Bill Todd
> Bill Todd <bill...@metrocast.net> writes:
>> Anton Ertl wrote:
>>> Bill Todd <bill...@metrocast.net> writes:
>>>> Place a NV flash cache in front of the disk and it need be destaged -
>>>> well, never, unless its dirty contents overflows the area alloted for it
>>>> (and the kinds of things that tend to be saved to disk on a laptop tend
>>>> to be smallish, so that shouldn't happen often).
>>> I would expect that the disk has to spin up more often for reading
>>> stuff that is not yet in RAM,
>> I question that, with laptop RAM complements rapidly approaching 1 GB
>> theses days: typical use should result in declining disk-read rates
>> over time as less and less cannot be found in the system RAM.
>>
>> Then again, I tend to save changes on a laptop as frequently as I do on
>> my desktop
>
> So how long does that take to fill a, say 128MB flash buffer?
Your comment ("I would expect..." above, continuing with "... And then
the writes can be destaged" below) is really difficult to interpret
other than as the suggestion that since the disk would have to spin up
frequently anyway for reading there was no real benefit in using flash
RAM to capture writes, and that's how I responded to it. So the
applicability of your most recent comment above puzzles me.
>
>>> and then the writes can be destaged,
>> Only if the disk is willing to wait a while to destage dirty data in its
>> write cache - which it really shouldn't be, since that decision is the
>> job of the OS-level write-back caching mechanism.
>
> The OS has already passed the stuff to the drive, and does not know
> and should not care whether it is on the rotating or the flash medium.
> The destaging I referred to is a purely drive-internal operation.
If you were indeed referring to destaging from flash to the platters
that may make your current response more understandable, but then I'm
not sure what the purpose of your earlier response was (just to observe
that the rare times when the flash cache was destaged could often be
handled opportunistically when the drive was already spun up?).
>
> So, once the drive has satisfied the read requests that caused it to
> spin up, and while it waits the, say, 30s period for any more read
> requests before it spins down, it can write the stuff back from the
> flash to the rotating medium.
>
>> I.e., once the OS thinks it's time to write data to disk (e.g., because
>> a user explicitly 'saved' it), the disk should get it onto its platters
>> as soon as is consistent with short-term performance optimization goals
>> (such as reordering it or, in the case of drives that don't support
>> large sequential transfers, aggregating it) rather than second-guess
>> higher-level software as to how important making it persistent may be.
>
> If it's in flash, it is persistent.
Indeed: as described above I had not thought you were talking about use
of flash.
>
>>>> My main reservations about such behavior would center around whether
>>>> flash memory has reliability - especially when frequently updated in
>>>> small increments
>>> Any reason to think that this is not the case?
>> My impression is that the probability of data loss from UPS-backed
>> conventional ECC RAM may be somewhat higher than that of data loss from
>> a disk (at least if one ignores whole-disk failure, which is appropriate
>> in this situation), but I could be mistaken or if not flash might differ
>> in that respect.
>
> Certainly. Flash does not need a UPS in order to keep its contents,
> so one less source of unreliability.
I'm afraid you've misunderstood me this time: my impression referred to
the probability of data loss with conventional RAM power loss factored out.
- bill
Anton Ertl
>Anton Ertl wrote:
>> Bill Todd <bill...@metrocast.net> writes:
>>> Anton Ertl wrote:
>>>> Bill Todd <bill...@metrocast.net> writes:
>>>>> Place a NV flash cache in front of the disk and it need be destaged -
>>>>> well, never, unless its dirty contents overflows the area alloted for it
>>>>> (and the kinds of things that tend to be saved to disk on a laptop tend
>>>>> to be smallish, so that shouldn't happen often).
>>>> I would expect that the disk has to spin up more often for reading
>>>> stuff that is not yet in RAM,
>If you were indeed referring to destaging from flash to the platters
>that may make your current response more understandable, but then I'm
>not sure what the purpose of your earlier response was (just to observe
>that the rare times when the flash cache was destaged could often be
>handled opportunistically when the drive was already spun up?).
Yes, it's a comment on your statement about when the destaging from
flash to platters would happen.
Jan Vorbrüggen
> activities should take longer from disk than from flash - as long as
> they've been optimized to execute from the disk in streaming sequential
> fashion (which unfortunately does not usually seem to have been done in
> current Windows environments - and perhaps others as well, FAIK - so the
> flash becomes a potentially useful feature only due to the uncorrected
> deficiencies of the OS).
I had been told that one of the few reasons to use W/XP over W/2K is that
in XP, Microsoft integrated a technology they bought that ensured boot time
disk reads are as sequential as possible. Watching other laptops boot con-
vinced me that there must be some merit to that rumor. Are you saying there
is not?
Jan
Bill Todd
I don't know - but I strongly suspect that no Windows environment
*really* executes boot-time reads 'as sequentially as possible', because
that would mean that they requested the entire required complement of
boot code and data in a single, lengthy sequential access (pre-loading
RAM initially with data that would not be required until later in the
boot process to avoid multiple reads).
Windows has had since at least Win98 mechanisms that reorganize the
layout of files on disk to *improve* load access times (and my
impression is not only at boot time), and likely has somewhat improved
them with subsequent versions of their OSs. But comparing current
desktop disk transfer rates of 40 - 80 MB/sec with observed Windows boot
times suggests that they've nowhere nearly optimized out *all*
unnecessary disk-access latency during the boot process.
My guess would be therefore that a few hundred MB of flash RAM might
still materially improve XP and Vista boot times if it were preloaded
for that purpose.
- bill
Stephen Sprunk
news:4ot5boF...@individual.net...
> I had been told that one of the few reasons to use W/XP over W/2K is
> that in XP, Microsoft integrated a technology they bought that ensured
> boot time disk reads are as sequential as possible. Watching other
> Are you saying there is not?
XP added some technology MS acquired (from Intel, IIRC) that tracks what
files were accessed during boot time and moves them all to the same area
of the disk to reduce _how far_ seeks have to go. It doesn't track the
individual reads, though, so there's still seeks.
Another thing XP added was being able to load multiple drivers in
parallel, versus prior versions loading each driver and its dependencies
sequentially. Since drivers apparently spend a lot of time thinking
between reads and loading other drivers, then stalled waiting for disk
reads, this helps a lot. Unfortunately, it conflicts with the first
improvement since now you have multiple drivers being loaded from
different files at the same time.
XP does boot noticeably faster than 2000; I've never benchmarked it, but
it makes a user-visible difference. Unfortunately, the disk still
thrashes, so it's not even close to sequential reads. In fact, the
grinding with XP is a lot louder and more constant than with 2000, where
the grinding would come and go over a longer period of time.
As someone said, using flash (which has negligible seek time) to fix
this is a hack to deal with the fact the boot process isn't very smart,
even in XP or Vista.
Why not just mark a section of disk to be loaded sequentially into the
disk cache at boot time, and store all the stuff the OS needs to boot in
that area?
Jan Vorbrüggen
> files were accessed during boot time and moves them all to the same area
> of the disk to reduce _how far_ seeks have to go. It doesn't track the
> individual reads, though, so there's still seeks.
Yeah, that's more like what I understand is happening. Still, on my laptop,
the disk seems to be very slow on seeks, so it makes a noticeable difference.
> Why not just mark a section of disk to be loaded sequentially into the
> disk cache at boot time, and store all the stuff the OS needs to boot in
> that area?
That seems to me to assume that every boot is the same - but it isn't. At
least, you have to take into account that some configuration stuff can have
changed, and of course there is the ever-continuing flow of patches and
updates. That makes your suggestion difficult to implement if taken naively.
Jan
Ketil Malde
> ([...] so the flash becomes a potentially useful feature [at boot
> time] only due to the uncorrected deficiencies of the OS).
Looking at Linux (cold) boot charts at
http://www.bootchart.org/samples.html
it seems that most of them spend a large amount of time (50%) waiting
for IO, but some have a much lower fraction (which of course could be
due to different services, sleeps or high cpu-consumption, rather than
less or better-organized IO)
Anton Ertl
[Someone wrote:]
>> Why not just mark a section of disk to be loaded sequentially into the
>> disk cache at boot time, and store all the stuff the OS needs to boot in
>> that area?
>
>That seems to me to assume that every boot is the same - but it isn't. At
>least, you have to take into account that some configuration stuff can have
>changed, and of course there is the ever-continuing flow of patches and
>updates.
That's why Windows XP records what is loaded at boot time, and
rearranges the stuff the next time you defragment the disk. So, if
your boot has changed too much and has slowed down significantly for
that reason, just run the defragmenter again. IIRC that works only
for NTFS, however.
Bernd Paysan
> Why not just mark a section of disk to be loaded sequentially into the
> disk cache at boot time, and store all the stuff the OS needs to boot in
> that area?
Put all the stuff the OS needs for booting into a compressed file image,
load it into RAM (as RAM disk). After booting is completed, throw that RAM
disk out.
Actually, that's how Linux starts the boot process, but only for the first
part. Then it uses a sluggish process, just like Windows.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Ketil Malde
> Looking at Linux (cold) boot charts at
Oh, and about optimizing the disk layout:
http://ubuntuforums.org/showthread.php?t=254263
There's a thing called 'readahead', that apparently stores an ordered
(by disk position) list of files that will be needed during boot, and
loads them all into RAM.
Niels Jørgen Kruse
> Ketil Malde <ketil...@ii.uib.no> writes:
>
> > Looking at Linux (cold) boot charts at
>
> Oh, and about optimizing the disk layout:
>
> http://ubuntuforums.org/showthread.php?t=254263
>
> There's a thing called 'readahead', that apparently stores an ordered
> (by disk position) list of files that will be needed during boot, and
> loads them all into RAM.
It's called bootcache in OS X. It works on the block level though.
--
Mvh./Regards, Niels Jørgen Kruse, Vanløse, Denmark
Stephen Sprunk
> [I said:]
>> Why not just mark a section of disk to be loaded sequentially into
>> the disk cache at boot time, and store all the stuff the OS needs to
>> boot in that area?
>
> That seems to me to assume that every boot is the same - but it isn't.
> At least, you have to take into account that some configuration stuff
> can have changed, and of course there is the ever-continuing flow of
> patches and updates. That makes your suggestion difficult to
> implement if taken naively.
XP already knows which files were accessed at last boot time, so that's
done. They're already in a contiguous space on disk too, so that's
done. All that's left is priming the disk cache with those contents via
sequential reads _before_ the OS tries reading the files instead of
waiting for them to be accessed in random order.
True, things may vary from boot to boot, but the vast majority of the
time this boot will be the same as the last one, and if not you have the
data available to fix it for next time. The naïve implementation is
good enough -- or at least better than what's there today.
ranjit_...@yahoo.com
> Stephen Sprunk wrote:
> I get the impression that 16Gbit flash chips are in same $ ballpark as
> 1GB DRAM parts so flash has won for now, flash prices plumet while DRAM
> appears to head back up again.
What you've written implies that you're comparing 16Gbit flash with
8Gbit DRAM chips. If there can be 16Gbit flash chips, why isn't there
an 8Gbit DRAM chip (which would make for 32GB DIMMs)?
rpl
<so....?>
The main real advantage of a 256MB on-drive Flash cache is that
file-use/event(/snooping) procedures won't require the HD to be spun up
every couple seconds if it's implemented correctly...
The faster boot/suspend times are useful mostly for laptop users and
infrequent desktop users.
However...
<sarcasm?>
Samsung is pushing it so that they don't have to retool to accomodate
their moving from a 3-year warranty to a 1-year warranty; the
"hard-drive spins up every 20 minutes" will take care of that nicely.
Also takes care of the 256MB chips that are clogging the warehouse. And
of course the $50 more the consumers pay for $7 more worth of
electronics is sorta cool too.
Microsoft is playing a mildly Machiavellian chess game:
a) Nifty new hard-drive is intro'd; programmable firmware allows other
OSes to play, too.
b) within a month, the noiseless faster boot/resume and invisible event-
logging/reporting get the thumbs up not only from shills but from junior
techie types. The sites that normally report M$ as being the invasive
crap it is note a slight increase in HD activity that doesn't make it to
the platters, but are ignored.
c) approximately 2 months after the intro, the easily written viruses
are noticed to be physically killing flash-caches left and right
d) M$ of course is "shocked" at how mean these dastards are and
implements another layer of crap in their "OS" requiring any programs
that access the hard-drive (and incidentally CD/DVD drives) to be
certificated by M$. M$ programs are the only ones allowed to reside in
the cache for "safety reasons", the last firmware update makes sure it
isn't programmable any more and the latest crap makes it impossible to
monitor HD activity through software. If you believe M$ is evil then
this is the biggest move they've ever made towards world-domination.
e) Samsung sympathizes with the screwed-over consumers, offers a free
(S/H not included) one-time replacement of the chips bundled with a
slightly extended warranty and announces that all warranties are void on
any non-patched M$ system.
The generic term "Flash Cache" gets a big PR blow which reduces the
possibility of further improvements in that area (which would reduce
hard-drive needs considerably)
</sarcasm?>
Usually when I write something like this, it's just for fun... that's
usually.