> From: Stephan Aßmus <superstippi@xxxxxx> > Subject: [haiku-development] Re: Writing Device Drivers - CRAM - Problem > uninit_driver() > > 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? Depends, I tune my compression code to the main contents of the ramdisk, I use a version of LZ that works nicely on text. But I am looking at other compressors that are tuned for object code. As an optional feature I think it could be a good idea. > > 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? Yes, but a single 256MB file adds 2 seconds to my boot time period. And then it is just there to use. > > 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? This ramdisk (versions 0.40 and greater) CAN be set to a size greater than available memory, and then pages out it`s extra data tracks to the different drives. At this point you gain in size of the drive at the expense of losing speed. > > 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. > That argument sounds strange to me. You could be very very right. There is a reason I said simple tests. Give me a little time and I will do some proper bench-marking.