Date: Mon, 29 Sep 2008 01:19:23 -0400 From: "Zaphod Beeblebrox" <zbeeble@gmail.com> To: "Michael Schuh" <michael.schuh@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: experimantal question about md's Message-ID: <5f67a8c40809282219w6ae93986od211c6e8c47066fe@mail.gmail.com> In-Reply-To: <1dbad3150809261115h379a611aweb20e47124e254d4@mail.gmail.com> References: <1dbad3150809261115h379a611aweb20e47124e254d4@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 26, 2008 at 2:15 PM, Michael Schuh <michael.schuh@gmail.com>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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5f67a8c40809282219w6ae93986od211c6e8c47066fe>