Hi, thank you for your answer.
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. so we have a webserver (par example) at this mirror it has very good speed for the file-access (ok i know in allmost cases is not the disk the bottleneck, and if we could doing caching...) at the above examle it is not really important if the write process needs a second or two longer, but by millions of requests it could be interseting to read the data very fast...... in my idea it was only focused on reads not on writes, the drawbacks of Raid are well known 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. in the case of my idea it is clearly..... but on the other side we need to have to say: Hi kernel, do never ever buffering on this rambased Diskdevice.... or we shoot us in our knees....as i think.... thank you michael 2008/9/29 Zaphod Beeblebrox <[EMAIL PROTECTED]> > > > On Fri, Sep 26, 2008 at 2:15 PM, Michael Schuh <[EMAIL PROTECTED]>wrote: > >> Hallo @list, >> >> Let us say i have a Machine with 8 CPUs and a lot of RAM. >> An i need a very high perfomance Storage for holding data. >> >> My idea was to setup a raid1(0) with virtual disk images. >> Created with mdconfig. >> >> My idea was to create minimum 2 md-diskimages, >> these are located >> fisrt one on the harddisk as type vnode >> second one as exact copy totally in the memory as type malloc >> >> For now the man-page mentoid me to not to do so, while large disks in RAM >> cause panics, and i know panics come surely >> >> Is the above scenario possible without panics? >> > > My first concern is not the panics (you can somewhat solve this by using > swap-backed MD), but the fact that you can't really gain an advantage this > way. > > If you have enough RAM, the regular process of filesystem buffering will do > the work for you. If you don't have enough RAM, the RAM starvation of > buffers and processes will be your problem and not the speed of your > filesystem. > > Regardless, if you were to construct a raid with an MD and a real disk (no > need to make it a vnode MD --- but that has the same drawbacks) the RAID > filesystem would be constrained by the speed of writes to the slower > filesystem. You may get a few percent out of teaching the gmirror node to > prefer reading from the memory disk, but would this be an advantage over the > natural buffering that already takes place? Probably not. > > -- === m i c h a e l - s c h u h . n e t === Michael Schuh Postfach 10 21 52 66021 Saarbrücken phone: 0681/8319664 mobil: 0177/9738644 @: m i c h a e l . s c h u h @ g m a i l . c o m === Ust-ID: DE251072318 === _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"