Re: [gentoo-user] Running out of space on /var partition

[Dale]

Joshua Murphy wrote:
> On Wed, Jul 27, 2011 at 5:51 PM, Dale<rdalek1967@×××××.com>  wrote:
>
>> Michael Mol wrote:
>>
>>> On Wed, Jul 27, 2011 at 5:07 PM, Dale<rdalek1967@×××××.com>    wrote:
>>>
>>>
>>>> Neil Bothwick wrote:
>>>>
>>>>
>>>>> On Wed, 27 Jul 2011 10:58:28 -0500, Dale wrote:
>>>>>
>>>>>
>>>>>
>>>> I have 16Gbs here.  It's not like I'm going to run out or anything.  I
>>>> can
>>>> put half on tmpfs and still have 8Gbs left.  That is more than enough to
>>>> compile even OOo with no space problems.
>>>>
>>>> Thoughts?
>>>>
>>>>
>>> This is Gentoo, where all us users are reputed to spend their days
>>> passing around benchmarks of "emerge -e world", right?
>>>
>>> Try it. :)
>>>
>>>
>>>
>>>
>> Yep, we do that.  Mine is about 12 hours.  I would post it but I got a
>> Blocker instead.  I'll work on that and post it later.  lol
>>
>> Point is, I have more than enough memory to test the theory that putting
>> portage's work directory on tmpfs is faster/slower than a hard drive.  I
>> tested it and it really didn't make much difference.  Most of the time it
>> was slower but a couple times it was faster but only by a few seconds.
>>
>> I guess drives are just a lot faster nowadays or at least fast enough.  I
>> dunno.
>>
>> Dale
>>
>> :-)  :-)
>>
>>
>>
> I would hazard a guess here that, rather than it being a benefit from
> improvement in drive speeds, it's moreso an improvement in the
> kernel's file caching. As I understand it (likely incorrectly) tmpfs
> essentially does little more than inject the given file into the
> filesystem cache, with a 'keep this here' flag attached to it. As
> files are accessed on the disk, they're pulled into the filesystem
> cache anyhow, and they stay there as long as they're being used and
> there's room to keep them. With tmpfs, every file you put into it
> stays until explicitly removed, wheras letting the kernel handle the
> selected list of files in the cache only keeps the ones the kernel
> feels are worth keeping. I am curious, though, whether *not* using
> -pipe will actually improve performance when building in tmpfs, as
> you're already sidestepping most of the overhead of creating files
> with tmpfs, so piping data rather than using intermediate files just
> creates extra memory usage overhead (which, while cheaper than disk
> i/o and filesystem metadata updates, is still overhead).
>
> Another likely source of performance loss in using tmpfs over physical
> disk to hold the build is that, by design, tmpfs occupies a portion of
> the filesystem cache. During a build, every header imported, every
> library linked, and every process that runs to make it all come
> together gets touched. When you touch files on disk, some or all of
> them get pulled into the filesystem cache, so keeping the entire build
> tree in the cache may well leave more frequently used files being
> dropped from cache to trade back and forth between one another.
>
> Again, all of this comes with a "I likely have no idea what I'm
> talking about, but it sounds convincing" disclaimer.
>
> :-)
>
>

Sounds better than my "I dunno" tho.  LOL

I know it doesn't make much sense tho, at least not based on what 
several others thought would happen way back in the day.  Back then, 
very few people had enough ram to really test this.  Those who did, 
well, it may not be their machine to run the test.  ;-)

I may test this again one day.  All you have to do is create a set and 
emerge it.  Reboot to make sure the cache is cleaned 100%, mount tmpfs 
and emerge the set again.  Compare the times and see what hits the fan, 
theory or reality.  :/

Dale

:-)  :-)