Hi,
On 22.08.2011 21:55, Earl Pottinger wrote:
The problem with that statement is that it does not includes some of
the extra features of the driver that do not exist in Haiku's cache code.
1) Compression: this let`s me hold a far larger percentage of the
drive image in ram than Haiku`s cache.
If it's so beneficial, maybe Haiku's disk caching should also use
compression?
3) Fake-Raid: the purpose is not to protect your data or make access
faster. What is gain is the ability to treat a bunch of drives as a
single drive, whit it`s size being the sum of the size of the
individual drives.
If the purpose is to chain some disks together to sum up their size, how
does a RAM disk help, which is limited to around 2GB?
4) Speed: I did some very simple speed tests, there is only a small
boost in speed compared to my Intel SSD. But I see a big difference
between my ramdisk and my IDE 40GB drives.
Note: My hard drive is an Intel 80GB SSD that I measured a transfer
rate of 158MB per second using 'dd', the ramdisk measures over 480MB
per second.
That argument sounds strange to me. In Haiku, the disk cache is not used
when it detects streaming access. I want the cache to be used for stuff
that is repeatedly needed. I don't want large files to be cached when I
just copy them from A to B, or a movie that I just watch. It doesn't
make sense to have that cached in RAM. Using dd as your test sounds like
it is probably detected as streaming, and thus gives you the raw device
speed even the second time around, as it should, since a user copying
the same files for a second time is really an uncommon use-case.
