Pdigmking <paugle@gmail.com> wrote:

If the answer is Yes, I'd like to tack on a follow up question.

Then how come buffer sizes are so small? Does making the buffer 32MB
add so much to the cost that people aren't willing to pay? Then
apparently it doesn't do much for performance. Or is it that adding
bigger buffers is more complex and expensive than just the memory?
Does it take special memory? Is it that most people just don't care
much about hard drive performance?

Sorry if that confuses things, I am really only asking one question.
How come (current typical) hard drive buffers are only 8 or 16MB?

Thank you.






--
I added the storage group because I think hard drive buffer size is
an interesting subject and the question is more appropriately
posted/asked there

John Doe <jdoe@usenet.love.invalid> wrote
That is just plain wrong, they have both.

Yep, you wouldnt be able to pick the drive with
the bigger cache without using a benchmark.

Basically because 2MB is plenty.

More that its pointless.

Correct.

Nope.

Yes.

Nope, it has minimal effect on performance.

Because that's fine.

In comp.sys.ibm.pc.hardware.storage John Doe <jdoe@usenet.love.invalid> wrote:
I think the problem is that in order to really speed up reading,
you would need more like 256MB and more of cache. What the small
sizes are good for is speeding up writes by buffering them. But
if you make these buffers too large, you might loose data if people
shut down their computer but the disk has not finished writing
when the power goes off.

Maybe the disk manufacturers do benchmarks with Windows on how
much time they have between the last write and the poweroff and
design buffer size accordingly...

The other possible reason is that it is SRAM, not DRAM as in
computer memory, and SRAM is more expensive.

Arno

In article <Xns9722B44588B01follydom@207.115.17.102>, John Doe says...

The idea of a buffer is twofold.

1) Cache frequently accessed files.
2) Hold data in fastest storage to make it immediately available to the
interface when the IDE/SATA port requests it.


--
Conor

"You're not married, you haven't got a girlfriend and you've never seen
Star Trek? Good Lord!" - Patrick Stewart, Extras.

Conor <conor.turton@gmail.com> wrote
Not with the buffer on the hard drive, thats done by the OS cache.

Its mostly used to buffer writes with hard drives.

"Arno Wagner" <me@privacy.net> wrote in message news:3vhiffF15r7l7U1@individual.net
A number plucked from your arse?

Hardly.
Even if the full cache were to be used it only gives a .1 second advantage.
Maybe if the drive is badly fragmented it may get slightly more noticeable.

We are talking cache here, not (just) buffer.
The 'cache' is divided in read cache, write cache and buffer.
Caches are divided in segments of which only a percentage is used
to buffer (read ahead, write behind), apart from the 'buffer', that is
only 128kB and buffers only a single command, whether read or write.
The rest is used to keep earlier instances of reads and writes and they
will be overwritten in time, usually oldest data first.

So obviously you are not talking about the cache as a whole.

Or it is just single chip memory that is differently organized than
computer memory and therefor not produced in the same quantity
as computer memory and consequently more expensive.

Not really.

HDD buffers are mostly to cache writes. Caching reads are done by the
application, OS or controller. Moving read caching to the drive is possible
but involves quite a lot more than plugging a few ICs into the board. Read
aching is not rocket science, conceptually, but implemeting it efficiently
and to yield positive impact is almost rocket science.


joe.

"Conor" <conor.turton@gmail.com> wrote in message
news:MPG.1dfda70fe4bafa9d98b6bb@news.individual.ne t...

Joe Yong <NO_flyingbuick_SPAM@yahoo.com> wrote

Particularly when done at the drive level when the drive
only knows about logical blocks and not about files etc.

Makes a lot more sense to do that sort
of caching at the OS level or the app level.

"Rod Speed" <rod_speed@yahoo.com> wrote in news:3vhf5bF1529atU1
@individual.net:


So Rod,

Your saying that 8MB doesn't really improve performance over 2MB?

By the way, I was referring to certain Samsung IDE drives which are now
only available with 2MB buffer, I realize that Samsung has drives with 8MB,
but he question remains.. 2 vs. 8?

Paul

Troll

"Folkert Rienstra" <see_reply-to myweb.nl> wrote:

Pdigmking <paugle@gmail.com> wrote
Nope, that the improvement in performance is quite small and 32MB
will make very little difference at all since its basically a write buffer.

Like I said, the difference is quite small.

"Joe Yong" <NO_flyingbuick_SPAM@yahoo.com> wrote in message news:qp_kf.8299$wF.3108@trnddc08
Apparently it is to you, judging by your post.

That's saying the same thing twice, more or less:
Caching "frequently accessed files" is "holding data in fastest storage to make it
immediately available to the interface when the IDE/SATA port requests it".

Presumably the second point is about caching ahead where a follow-up request
to a previous request for parts of a sequential file is cached even before the
followup request is issued and when it is issued the data comes from cache rather
than from the platters.

And then there is 3) and 4) as well, for the write cache side of the cache.

Let's see those headers again, John Troll.

"Rod Speed" <rod_speed@yahoo.com> wrote in message news:3vjgksF16ffeiU1@individual.net
It doesn't need to know about files.
A file is represented by block numbers and if a particular file is
requested it is requested by those blocknumbers. If those blocknumbers
happen to be available in cache, then that is where they will come from.

Read-ahead caching is not about pre-emptive file caching, it is about caching
sectors that are likely to be read next by the next IO but which IO may not
arrive in time so that when it eventually does the data is available without
having to wait a revolution to still pick that data up.

Both don't know about your files either.
All they can do is load files that are adjacent to the file that you are loading
but that does nothing for the file that you are loading and the files that are
adjacent to the file that you are loading may have nothing whatsoever to do
with the app that you are using.

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in
news:4394e2a3$0$71102$892e7fe2@authen.yellow.readf reenews.net:

....and for sequential file reads this will work better if the disk
files are not fragmented.

Folkert Rienstra <see_reply-to@myweb.nl> wrote
Wrong when deciding what to cache. Most obviously with
caching directory structures in preference to files etc.

Irrelevant to deciding what its more important to cache.

It was caching in general that was being
discussed, not just read ahead caching.

See above.

Wrong again.

Wrong again.

Never said it did.

Never said they did.

The OS can obviously distinguish between directory structures
that are more likely to be used again and files loaded by apps,
can know what processes requested which files and which
processes are no longer running and so are less likely to
request that file again, etc etc etc.

In spades with the apps where decent database apps can be
a lot more intelligent about what data they cache internally etc.

Thanks for that completely superfluous proof that you have never
ever had a fucking clue about anything at all and couldnt manage
a viable troll if your pathetic excuse for a 'life' depended on it.