Michael Schuh wrote: > Clearly the Writeprocess of writeing data to an mirror is totally ended, as > all mirrordevices are written. > But for the read the kernel uses the faster device......and there it could > be an advantage.....i m thinking. > And yes i think it could be an advantage, if the RAMed mirror is very fast, > we have only to wait > for the first initialization, all the ongoing reads go to the ramdisk, all > writes goes to both devices.
I think it would be completely sufficient to use a normal device and let the kernel cache the data. This is much better because the kernel dynamically adapts the cache size to the workload and memory requirements. If you use an unusual asymmetric mirror setupt with a physical disk and a memory disk (swap-backed), the machine will have to start paging as soon as the requirements of your processes grow beyond what's available. This will be very slow, of course. For example (a little bit simplified): Say there's a spike in web accesses so you get many processes that want to allocate memory. If you run out of free memory, the kernel will drop some pages that contain cached data and re-use them. If the cached data is used later, the kernel will re-read it from the disk. On the other hand, if you use a memory disk, you effectively reduce the amount of memory available by the size of that disk. If a process wants to allocate memory now, the kernel can't simply drop any pages used by the memory disk -- it has to write them to the swap area first. It is obvious that the performance is worse. And of course, the kernel will still try to cache the file system data (the VFS code doesn't care that the file system is on a gmirror with one half on a memory disk). So the cache and the memory disk fight for RAM at the same time. Basically you would be wasting RAM and losing performance. > if i have enough ram in the box, it is possible to say: Hi kernel use plase > 8 Gigs of ram for buffering > the directory abc on the disk directaccesABC ??? i think not. The kernel will basically use all available RAM for caching and buffering. This works especially well for static web content. There are a few sysctl variables to influence the behaviour, but it's usually better not to touch them. I get the impression that you're trying to solve a problem that doesn't exist. If you think you _do_ have a problem, please provide some evidence, such as output from iostat, gstat, vmstat and so on. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is to C as Lung Cancer is to Lung." -- Thomas Funke _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
