experimantal question about md's

Michael Schuh michael.schuh at gmail.com
Mon Sep 29 08:36:48 UTC 2008


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 <zbeeble at gmail.com>

>
>
> On Fri, Sep 26, 2008 at 2:15 PM, Michael Schuh <michael.schuh at 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.
>
>


-- 
=== 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 ===


More information about the freebsd-hackers mailing list