[haiku-development] Re: Writing Device Drivers - CRAM - Problem uninit_driver()

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? 


2) Pre-loading: this means on the solid image (single file) version of the 
ramdisk I just boot and all the data contained in the ramdisk is loaded by the 
time booting has finished.
That sounds like only the times are shifting around: Isn't your boot time much slower as a result? 


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. 

Best regards,
-Stephan

Other related posts: