Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] tmpfs

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: "Sergey A. Lipnevich" <sergeyli AT pisem.net>
  • To: Phil/CERisE/KG6MBQ <cerise AT littlegreenmen.armory.com>
  • Cc: Source Mage Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] tmpfs
  • Date: Sat, 27 Jul 2002 03:27:43 +0400 (MSD)

Phil,

My Dell Inspiron 5000 with Pentium III 700 MHz and 256
MB RAM just showed a faster result for tempfs while
building openldap :-). Now, I'm sure that disk-based
compilation would be even slower if benchmarked
properly because GKRellM was showing quite clearly how
effective reiserfs cacheing is working on openldap
source files. That means, if I rebooted before
compiling off reiserfs, there would be additional time
spent on reading sources from the disk. Anyway, I
wouldn't proclaim tempfs losing before seriously
testing it in terms of performance and fragmentation
impact, before saying "shown by benchmarks" etc. I'd go
as far as saying that nothing on this list has shown
that anything is wrong with choosing tempfs.
Take care!

Sergey.


Phil/CERisE/KG6MBQ <cerise AT littlegreenmen.armory.com>:

> Laurent Wandrebeck said:
>
> > hi ppl !
> > please note that I may have had a completely stupid
idea :)
> > Even if tmpfs is a bit slower than using disk
space, i think
> > that limiting fragmentation is a Good Idea (tm).
i've been wondering
> > if the use of ramdisk wouldn't be better. doc says
that it dynamically
> > grows as more space is required. Moreover, it uses
a real filesystem,
> > which is not the case of tmpfs afaik, so it might
be faster.
> > anyway, i know that size grows, but i've seen
nothing in docs about
> > freeing memory which is no more used...
>
> Ramdisk would be an even worse way to implement it.
It would suck more
> memory and would require formatting to use a real
filesystem.
>
> I still fail to see how on a modern filesystem,
fragmentation becomes
> an issue. There hasn't been any benchmarks or
convincing arguments
> to that effect. Given the number of times that I've
run similar
> projects on my system and the insignificant amount of
fragmentation,
> I'd tend to say that it's not a worry at all.
>
> I did notice that the reports of fragmentation were
on small partitions
> (e.g. boot). Higher fragmentation is simply to be
expected on a
> smaller partition and having the tarball around is
going to
> significantly affect it as is.
>
> But, whatever. What seems obvious to my experience
and analysis and
> has been shown by benchmarks to be true is apparently
against some
> sort of underground religion here.
>
> I don't mean to start that argument again though.
It's clear that
> nothing will be gained by it.
>
> OTOH, if people want the proven-to-be-slower tmpfs in
Sorcery as
> an option, then it only makes sense to include the
> probably-equally-as-slow ramdisk as well. You
certainly have a good
> logical basis to argue it, if you so wish.
>
> -Phil/CERisE
>
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
>
>



Sergey Lipnevich, MCSE, SCPJ,
Sr. Software Engineer,
New Age Network New York, Inc.,
+1-848-459-LIPN.




Archive powered by MHonArc 2.6.24.

Top of Page