On 5/8/07, Oliver Fromme <[EMAIL PROTECTED]> wrote:
Mars G. Miro wrote:
> Oliver Fromme wrote:
> > By the way, what are you actually trying to do? What is
> > your goal? Do you need to reduce the buildworld time?
>
> as i've mentioned in my original email, does mfs speed up I/O stuff ?
Sometimes it does. But most of the time, a real disk
partition with soft-updates on it is just as fast.
With soft-updates, writing is asynchronous, i.e. it
goes to RAM first, just like a memory disk. The data
is later committed to disk in the background, so the
processes don't have to wait for it. And once the
data is in the cache, reading is just as fast (or even
faster) as a memory disk. Note that /usr/src will
fit in the cache easily if you have several GB of RAM.
I usually have a memory disk as /tmp, but that's really
just for historical reasons. And it's easier to clean
up -- just umount it. ;-)
> there's been a lot of threads in teh past that a buildworld on mfs
> increases speed --- tho it might not be the appropriate test for
> high-end machines (speaking of w/c I just gots a T2000).
It depends on what exactly you want to test, and for
what reason. You probably have already wasted much
more time with your experiments and testing than you
can ever save by using mfs for buildworld.
wasted my time? dont think so.
now we know buildworld on mfs dont really matter on high-end machines,
and it didnt even then when i tried it on my single-proc Opteron w/ 1G
of RAM almost 2 years ago on 5.X (i recall having to crash when i used
malloc but then this is documented)
and I'd think testing it on something like my x4100 w/ 8G of RAM may
produce the same results..
so teh conclusion would be, buildworld isnt teh appropriate test if
mfs does really speed things up, other apps/tools may be much more
appropriate --- that or, does mfs speeding things up really work?
remains to be seen ...
> there's prolly other appropriate apps/tools for mfs-testing ...
I don't think it makes much sense to benchmark mfs.
It is a known fact that a real tmpfs (like Solaris and
Linux have) would be better. I think it's even listed
on the FreeBSD ideas web page, but nobody is actively
working on it, AFAIK. On the other hand, I'm not 100%
convinced that it would be worth the effort either.
it does to me, however, and perhaps other people too ;-)
It would be interesting to see how ZFS on a swap-backed
vnode device would perform on FreeBSD 7-current (with
and without compression).
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
One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.
cheers
mars
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
