[gentoo-user] /var/tmp on tmpfs

[gentoo-user] /var/tmp on tmpfs

[gevisz]

I never used tmpfs for portage TMPDIR before and now decided to give it a try.

I have 8GB of RAM and 12GB of swap on a separate partition.

Do I correctly understood https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs
that I can safely set in the fstab the size of my tmpfs to 12GB so
that the chromium
could be emerged in tmpfs (using the swap) without the need to set notmpfs.conf
for chromium and the likes.

And I am going to set the whole /var/tmp/ on tpmfs instead of just
/var/tmp/portage
Is it ok?

[gentoo-user] Re: /var/tmp on tmpfs

[Nikos Chantziaras]

On 08/02/18 19:11, gevisz wrote:
> I never used tmpfs for portage TMPDIR before and now decided to give it a try.
> 
> I have 8GB of RAM and 12GB of swap on a separate partition.
> 
> Do I correctly understood https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs
> that I can safely set in the fstab the size of my tmpfs to 12GB so
> that the chromium
> could be emerged in tmpfs (using the swap) without the need to set notmpfs.conf
> for chromium and the likes.
> 
> And I am going to set the whole /var/tmp/ on tpmfs instead of just
> /var/tmp/portage
> Is it ok?

If you're not using ccache, then you don't need /var/tmp to be on tmpfs. 
You should only put /var/tmp/portage on tmpfs.

If you do use ccache, then you need to mount both /var/tmp and 
/var/tmp/portage as tmpfs. Although if you end up swapping, it's 
probably going to be slower than not using tmpfs. So unless you have 
something like 32GB of RAM, it might be best to use notmpfs.conf for 
Chromium anyway.

(Although I didn't benchmark swap vs notmpfs.conf. Swap being slower 
than notmpfs.conf is just an educated guess.)

Re: [gentoo-user] Re: /var/tmp on tmpfs

[Rich Freeman]

On Thu, Feb 8, 2018 at 12:47 PM, Nikos Chantziaras <realnc@gmail.com> wrote:
> On 08/02/18 19:11, gevisz wrote:
>>
>> I never used tmpfs for portage TMPDIR before and now decided to give it a
>> try.
>>
>> I have 8GB of RAM and 12GB of swap on a separate partition.
>>

You can try it, but for Chromium these days you might find that still
doesn't perform great.  I have 16GB of RAM (no swap) and have moved
back to building on SSD for that one package (with ccache to help).

>
>
> If you're not using ccache, then you don't need /var/tmp to be on tmpfs. You
> should only put /var/tmp/portage on tmpfs.

I disagree on this.  Unless you have something that uses gobs of space
on /var/tmp there is little reason not to make the whole thing a
tmpfs.

> If you do use ccache, then you need to mount both /var/tmp and
> /var/tmp/portage as tmpfs.

I DEFINITELY disagree on this one.  What is the point of using ccache
and then storing it on tmpfs, unless it is just for dealing with
short-term build failures?  The whole point of ccache is to re-use the
results of previous builds, and sticking it on tmpfs defeats that.  If
you're going to just store it on tmpfs you might as well not use
ccache at all and free up a ton of RAM for the rest of the build.

Maybe I could see this sort of thing being used in niche situations,
such as if you are a developer on some project and build the same
thing 20 times per day between reboots.  If you only build a package
once per reboot then having a ccache on tmpfs provides no benefit at
all, and just eats vram and creates more swap writes (though probably
not reads).

-- 
Rich

[gentoo-user] Re: /var/tmp on tmpfs

[Nikos Chantziaras]

On 08/02/18 20:13, Rich Freeman wrote:
>> If you're not using ccache, then you don't need /var/tmp to be on tmpfs. You
>> should only put /var/tmp/portage on tmpfs.
> 
> I disagree on this.  Unless you have something that uses gobs of space
> on /var/tmp there is little reason not to make the whole thing a
> tmpfs.

True. But I only said that's it's not needed. You can do it regardless.


>> If you do use ccache, then you need to mount both /var/tmp and
>> /var/tmp/portage as tmpfs.
> 
> I DEFINITELY disagree on this one.  What is the point of using ccache
> and then storing it on tmpfs, unless it is just for dealing with
> short-term build failures?

But above you said you should be putting /var/tmp on tmpfs :-P

Anyway, I was wrong about needing to put /var/tmp on tmpfs when using 
ccache. The correct thing to say is that *if* you put /var/tmp on tmpfs 
*and* are using ccache, then you need to make sure it's large enough to 
accommodate /var/tmp/portage as well as ccache's files.

Re: [gentoo-user] /var/tmp on tmpfs

[Dale]

gevisz wrote:
> I never used tmpfs for portage TMPDIR before and now decided to give it a try.
>
> I have 8GB of RAM and 12GB of swap on a separate partition.
>
> Do I correctly understood https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs
> that I can safely set in the fstab the size of my tmpfs to 12GB so
> that the chromium
> could be emerged in tmpfs (using the swap) without the need to set notmpfs.conf
> for chromium and the likes.
>
> And I am going to set the whole /var/tmp/ on tpmfs instead of just
> /var/tmp/portage
> Is it ok?
>
>


I have 16GBs of memory here and have /var/tmp/portage/ on tmpfs, no
ccache.  With the growing size of packages, I've had to put several on
regular spinning rust to make sure enough space is available.  This is
my list, so far.

www-client/firefox
www-client/seamonkey
app-office/libreoffice
sys-devel/gcc
dev-qt/qtwebengine
dev-qt/qtwebkit 

Those are the ones that tend to run into space problems.  Keep in mind,
I have twice the memory you have.  As someone else pointed out, if you
start using swap, that generally defeats the purpose of tmpfs. 

While I'm sure plenty of packages will make good use of portage being on
tmpfs, there will be quite a few that will have space problems.  You
will need to be ready to make exceptions for those as they show up but
those in my list are certainly ones that you may want to add before
trying.  There could be exceptions to this based on your habits and
memory requirements for other things but that is my experience so far. 

Hope that helps.

Dale

:-)  :-) 

[gentoo-user] Re: /var/tmp on tmpfs

[Nikos Chantziaras]

On 08/02/18 21:17, Dale wrote:
> I have 16GBs of memory here and have /var/tmp/portage/ on tmpfs, no
> ccache.  With the growing size of packages, I've had to put several on
> regular spinning rust to make sure enough space is available.  This is
> my list, so far.
> 
> www-client/firefox
> www-client/seamonkey
> app-office/libreoffice
> sys-devel/gcc
> dev-qt/qtwebengine
> dev-qt/qtwebkit

I'm on 16GB as well, with a 9GB /var/tmp/portage tmpfs, and all of the 
above build fine. No need to build them on disk.

Note that tmpfs does not consume any memory if there's no files in it! 
So you can make your tmpfs larger. Here, 9GB is enough to build the 
above. However, that's of course for when not using --jobs for emering. 
Just regular -jN in MAKEOPTS.

Re: [gentoo-user] Re: /var/tmp on tmpfs

[Rich Freeman]

On Thu, Feb 8, 2018 at 2:05 PM, Nikos Chantziaras <realnc@gmail.com> wrote:
> On 08/02/18 20:13, Rich Freeman wrote:
>>>
>>> If you're not using ccache, then you don't need /var/tmp to be on tmpfs.
>>> You
>>> should only put /var/tmp/portage on tmpfs.
>>
>>
>> I disagree on this.  Unless you have something that uses gobs of space
>> on /var/tmp there is little reason not to make the whole thing a
>> tmpfs.
>
>
> True. But I only said that's it's not needed. You can do it regardless.
>

We're on the same page here.

>
>>> If you do use ccache, then you need to mount both /var/tmp and
>>> /var/tmp/portage as tmpfs.
>>
>>
>> I DEFINITELY disagree on this one.  What is the point of using ccache
>> and then storing it on tmpfs, unless it is just for dealing with
>> short-term build failures?
>
> But above you said you should be putting /var/tmp on tmpfs :-P

I would also avoid putting ccache in /var/tmp for this reason.  I
suppose it is disposable but I'd think you'd want a different
retention policy than most stuff in /var/tmp.

In any case, ccache is only useful to the extent that you actually
re-use it, so purging it every time you reboot is usually
counterproductive, though it could be situational.


-- 
Rich

Re: [gentoo-user] /var/tmp on tmpfs

[Rich Freeman]

On Thu, Feb 8, 2018 at 2:17 PM, Dale <rdalek1967@gmail.com> wrote:
> As someone else pointed out, if you
> start using swap, that generally defeats the purpose of tmpfs.
>

I'll just add one thing to this, which I've probably already said ages ago:

In an ideal world swap would STILL be better than building on disk,
because it gives the kernel fewer constraints around what gets written
to disk.

Anything written to disk MUST end up on the disk within the dirty
writeback time limit.  Anything written to tmpfs doesn't ever have to
end up on disk, and if it is swapped the kernel need not do it in any
particular timeframe.  Also, the swapfile doesn't need the same kinds
of integrity features as a filesystem, which probably lowers the cost
of writes somewhat (if nothing else after a reboot there is no need to
run tmpreaper on it).

So, swapping SHOULD still be better than building on disk, because any
object file that doesn't end up being swapped is a saved disk IO, and
the stuff that does get swapped will hopefully get written at a more
opportune time vs forcing the kernel to stop what is doing after 30s
(by default) to make sure that something gets written no matter what
(if it wasn't deleted before then).

That's all in an ideal world.  In practice I've never found the kernel
swapping algorithms to be the best in the world, and I've seen a lot
of situations where it hurts.  I run without a swapfile for this
reason.  It pains me to do it because I can think of a bunch of
reasons why this shouldn't help, and yet for whatever reason it does.

-- 
Rich

Re: [gentoo-user] /var/tmp on tmpfs

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

On 02/08/2018 10:11 AM, gevisz wrote:
> And I am going to set the whole /var/tmp on tpmfs instead of just 
> /var/tmp/portage
> 
> Is it ok?

I don't know about the context of emerging, but I do know about the 
context of /var/tmp being volatile.

More specifically, /var/tmp is traditionally supposed to be non-volatile 
(across reboots).

Comparatively the contents of /tmp can be volatile (across reboots).

I would advise against mounting /var/tmp on tmpfs.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [gentoo-user] Re: /var/tmp on tmpfs

[gevisz]

2018-02-08 19:47 GMT+02:00 Nikos Chantziaras <realnc@gmail.com>:
> On 08/02/18 19:11, gevisz wrote:
>>
>> I never used tmpfs for portage TMPDIR before and now decided
>> to give it a try.
>>
>> I have 8GB of RAM and 12GB of swap on a separate partition.
>>
>> Do I correctly understood
>> https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs
>> that I can safely set in the fstab the size of my tmpfs to 12GB so
>> that the chromium
>> could be emerged in tmpfs (using the swap) without the need to set
>> notmpfs.conf
>> for chromium and the likes.
>>
>> And I am going to set the whole /var/tmp/ on tpmfs instead of just
>> /var/tmp/portage
>> Is it ok?
>
>
> If you're not using ccache, then you don't need /var/tmp to be on tmpfs. You
> should only put /var/tmp/portage on tmpfs.

Thank you for the reply.

I do not use ccache, and in my /var/tmp I only have /var/tmp/portage
and /var/tmp/genkernel (I use genkernel to generate initramfs image).

I never use emerge and genkernel at the same time. So, why not to put
the whole /var/tmp into one tmpfs?

> If you do use ccache, then you need to mount both /var/tmp and
> /var/tmp/portage as tmpfs. Although if you end up swapping, it's probably
> going to be slower than not using tmpfs. So unless you have something like
> 32GB of RAM, it might be best to use notmpfs.conf for Chromium anyway.
>
> (Although I didn't benchmark swap vs notmpfs.conf. Swap being slower than
> notmpfs.conf is just an educated guess.)

Re: [gentoo-user] Re: /var/tmp on tmpfs

[gevisz]

2018-02-08 20:13 GMT+02:00 Rich Freeman <rich0@gentoo.org>:
> On 08/02/18 19:11, gevisz wrote:
>>
>> I never used tmpfs for portage TMPDIR before and now decided to give it a
>> try.
>>
>> I have 8GB of RAM and 12GB of swap on a separate partition.
>>
>> Do I correctly understood
>> https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs
>> that I can safely set in the fstab the size of my tmpfs to 12GB so
>> that the chromium could be emerged in tmpfs (using the swap)
>>  without the need to set notmpfs.conf for chromium and the likes.
>
> You can try it, but for Chromium these days you might find that still
> doesn't perform great.  I have 16GB of RAM (no swap) and have moved
> back to building on SSD for that one package (with ccache to help).
>
> In an ideal world swap would STILL be better than building on disk,
> because it gives the kernel fewer constraints around what gets written
> to disk.

> Anything written to disk MUST end up on the disk within the dirty
> writeback time limit.  Anything written to tmpfs doesn't ever have to
> end up on disk, and if it is swapped the kernel need not do it in any
> particular timeframe.  Also, the swapfile doesn't need the same kinds
> of integrity features as a filesystem, which probably lowers the cost
> of writes somewhat (if nothing else after a reboot there is no need to
> run tmpreaper on it).

> So, swapping SHOULD still be better than building on disk, because any
> object file that doesn't end up being swapped is a saved disk IO, and
> the stuff that does get swapped will hopefully get written at a more
> opportune time vs forcing the kernel to stop what is doing after 30s
> (by default) to make sure that something gets written no matter what
> (if it wasn't deleted before then).

Thank you for the reply.

I probably try a pure tmpfs + swap solution. If it fails some day, I will
then add notmpfs exceptions.

However, it probably won't be sooner than
# emerge --update --deep --with-bdeps=y --newuse --backtrack=90 --ask
world --exclude chromium
fails because of the "--exclude chromium" part :), as I have already compiled
the recent vertion of chromium with /var/tmp/portage on the hard disk and
it took more than 24 hours on my old AMD Athlon X2 with j2 option. :(

Re: [gentoo-user] Re: /var/tmp on tmpfs

[Rich Freeman]

On Thu, Feb 8, 2018 at 4:52 PM, gevisz <gevisz@gmail.com> wrote:
>
> However, it probably won't be sooner than
> # emerge --update --deep --with-bdeps=y --newuse --backtrack=90 --ask
> world --exclude chromium
> fails because of the "--exclude chromium" part :), as I have already compiled
> the recent vertion of chromium with /var/tmp/portage on the hard disk and
> it took more than 24 hours on my old AMD Athlon X2 with j2 option. :(
>

Honestly I doubt that tmpfs will make much difference since this is
probably CPU-bound.

Using the jumbo-build option probably will help a lot more - but it
will use even more RAM and might make a tmpfs impractical for you.  I
bet that jumbo-build on a spinning disk will be faster for you than
not using that option on a tmpfs.  But, there is only one way to be
sure.

-- 
Rich

Re: [gentoo-user] /var/tmp on tmpfs

[gevisz]

2018-02-08 21:17 GMT+02:00 Dale <rdalek1967@gmail.com>:
> gevisz wrote:
>> I never used tmpfs for portage TMPDIR before and now decided to give it a try.
>>
>> I have 8GB of RAM and 12GB of swap on a separate partition.
>>
>> Do I correctly understood https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs
>> that I can safely set in the fstab the size of my tmpfs to 12GB so
>> that the chromium
>> could be emerged in tmpfs (using the swap) without the need to set notmpfs.conf
>> for chromium and the likes.
>>
>> And I am going to set the whole /var/tmp/ on tpmfs instead of just
>> /var/tmp/portage
>> Is it ok?
>
> I have 16GBs of memory here and have /var/tmp/portage/ on tmpfs, no
> ccache.  With the growing size of packages, I've had to put several on
> regular spinning rust to make sure enough space is available.  This is
> my list, so far.
>
> www-client/firefox
> www-client/seamonkey
> app-office/libreoffice
> sys-devel/gcc
> dev-qt/qtwebengine
> dev-qt/qtwebkit

Thank you for your reply and the notmpfs exception list.
I think it would be helpfull not only for me.

> Those are the ones that tend to run into space problems.  Keep in mind,
> I have twice the memory you have.  As someone else pointed out, if you
> start using swap, that generally defeats the purpose of tmpfs.
>
> While I'm sure plenty of packages will make good use of portage being on
> tmpfs, there will be quite a few that will have space problems.  You
> will need to be ready to make exceptions for those as they show up but
> those in my list are certainly ones that you may want to add before
> trying.  There could be exceptions to this based on your habits and
> memory requirements for other things but that is my experience so far.
>
> Hope that helps.
>
> Dale
>
> :-)  :-)
>

Re: [gentoo-user] Re: /var/tmp on tmpfs

[gevisz]

2018-02-08 23:57 GMT+02:00 Rich Freeman <rich0@gentoo.org>:
> On Thu, Feb 8, 2018 at 4:52 PM, gevisz <gevisz@gmail.com> wrote:
>>
>> However, it probably won't be sooner than
>> # emerge --update --deep --with-bdeps=y --newuse --backtrack=90 --ask
>> world --exclude chromium
>> fails because of the "--exclude chromium" part :), as I have already compiled
>> the recent vertion of chromium with /var/tmp/portage on the hard disk and
>> it took more than 24 hours on my old AMD Athlon X2 with j2 option. :(
>>
>
> Honestly I doubt that tmpfs will make much difference since this is
> probably CPU-bound.

Thank you for your reply.

You probably will be surprised, but the main reason I am trying to use
tmpfs for /var/tmp/ is not because I want to make emerging chromium
faster (I have no hope about that because read somewhere that it will
make compilation only 10 percent faster) but because I have not too
much free space on / (sometimes in the past chromium refused to build
in the similar conditions) and because of that either have to move /var/tmp
to the separate partition anyway or try to use tmpfs + swap and, if it fails,
to move to the separate partition only /var/tmp/portage/notmpfs

> Using the jumbo-build option probably will help a lot more - but it
> will use even more RAM and might make a tmpfs impractical for you.  I
> bet that jumbo-build on a spinning disk will be faster for you than
> not using that option on a tmpfs.  But, there is only one way to be
> sure.

[gentoo-user] Re: /var/tmp on tmpfs

[Nikos Chantziaras]

On 08/02/18 23:31, gevisz wrote:
> I do not use ccache, and in my /var/tmp I only have /var/tmp/portage
> and /var/tmp/genkernel (I use genkernel to generate initramfs image).
> 
> I never use emerge and genkernel at the same time. So, why not to put
> the whole /var/tmp into one tmpfs?

Well, someone here posted that /var/tmp is supposed to persist between 
reboots. So I'm not sure.

Anyway, I don't think it's going to make any difference in system 
performance when putting /var/tmp on tmpfs. There's almost nothing in 
there. Putting /var/tmp/portage on tmpfs is what's going to help with 
emerges. It will give a bit better emerge times as well as lower 
fragmentation on your disk.

Re: [gentoo-user] Re: /var/tmp on tmpfs

[gevisz]

2018-02-09 0:19 GMT+02:00 Nikos Chantziaras <realnc@gmail.com>:
> On 08/02/18 23:31, gevisz wrote:
>>
>> I do not use ccache, and in my /var/tmp I only have /var/tmp/portage
>> and /var/tmp/genkernel (I use genkernel to generate initramfs image).
>>
>> I never use emerge and genkernel at the same time. So, why not to put
>> the whole /var/tmp into one tmpfs?
>
>
> Well, someone here posted that /var/tmp is supposed to persist between
> reboots.

In this case it would be nice to hear a reason.
That's why I have asked if it does not harm.

> Anyway, I don't think it's going to make any difference in system
> performance when putting /var/tmp on tmpfs. There's almost nothing in there.
> Putting /var/tmp/portage on tmpfs is what's going to help with emerges. It
> will give a bit better emerge times as well as lower fragmentation on your
> disk.
>
>

[gentoo-user] Re: /var/tmp on tmpfs

[Nikos Chantziaras]

On 08/02/18 23:57, Rich Freeman wrote:
> On Thu, Feb 8, 2018 at 4:52 PM, gevisz <gevisz@gmail.com> wrote:
>>
>> However, it probably won't be sooner than
>> # emerge --update --deep --with-bdeps=y --newuse --backtrack=90 --ask
>> world --exclude chromium
>> fails because of the "--exclude chromium" part :), as I have already compiled
>> the recent vertion of chromium with /var/tmp/portage on the hard disk and
>> it took more than 24 hours on my old AMD Athlon X2 with j2 option. :(
>>
> 
> Honestly I doubt that tmpfs will make much difference since this is
> probably CPU-bound.

The lack of disk I/O improves the desktop while using it. Build times 
get slightly lower, but as you said, not enough as to be the main use. 
It's really about avoiding disk I/O. Another benefit is reducing 
fragmentation on the disk.

Re: [gentoo-user] Re: /var/tmp on tmpfs

[Rich Freeman]

On Thu, Feb 8, 2018 at 5:32 PM, gevisz <gevisz@gmail.com> wrote:
> 2018-02-09 0:19 GMT+02:00 Nikos Chantziaras <realnc@gmail.com>:
>> On 08/02/18 23:31, gevisz wrote:
>>>
>>> I do not use ccache, and in my /var/tmp I only have /var/tmp/portage
>>> and /var/tmp/genkernel (I use genkernel to generate initramfs image).
>>>
>>> I never use emerge and genkernel at the same time. So, why not to put
>>> the whole /var/tmp into one tmpfs?
>>
>>
>> Well, someone here posted that /var/tmp is supposed to persist between
>> reboots.
>
> In this case it would be nice to hear a reason.
> That's why I have asked if it does not harm.
>

Countless linux systems are configured to not preserve it between
reboots, FHS notwithstanding.  That said, whether you preserve it
would probably make the difference between whether sticking ccache in
there is a good idea or not.

Personally I don't preserve it, because lots of stuff that has no need
to persist ends up in /var/tmp.  I put stuff that should stick around
someplace else with a suitably liberal tmpreaper policy.

-- 
Rich

Re: [gentoo-user] Re: /var/tmp on tmpfs

[Tsukasa Mcp_Reznor]

[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]


________________________________
From: freemanrich@gmail.com <freemanrich@gmail.com> on behalf of Rich Freeman <rich0@gentoo.org>
Sent: Thursday, February 8, 2018 5:38 PM
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: /var/tmp on tmpfs

On Thu, Feb 8, 2018 at 5:32 PM, gevisz <gevisz@gmail.com> wrote:
>> 2018-02-09 0:19 GMT+02:00 Nikos Chantziaras <realnc@gmail.com>:
>>> On 08/02/18 23:31, gevisz wrote:
>>>>
>>>> I do not use ccache, and in my /var/tmp I only have /var/tmp/portage
>>>> and /var/tmp/genkernel (I use genkernel to generate initramfs image).
>>>>
>>>> I never use emerge and genkernel at the same time. So, why not to put
>>>> the whole /var/tmp into one tmpfs?
>>>
>>>
>>> Well, someone here posted that /var/tmp is supposed to persist between
>>> reboots.
>>
>> In this case it would be nice to hear a reason.
>> That's why I have asked if it does not harm.
>>

>Countless linux systems are configured to not preserve it between
>reboots, FHS notwithstanding.  That said, whether you preserve it
>would probably make the difference between whether sticking ccache in
>there is a good idea or not.

>Personally I don't preserve it, because lots of stuff that has no need
>to persist ends up in /var/tmp.  I put stuff that should stick around
>someplace else with a suitably liberal tmpreaper policy.

>--
>Rich


Just adding my 2 cents EMERGE_DEFAULT_OPTS="--fail-clean" helps a ton with tmpfs.
As for the athlon x2 system, consider using distcc, I've been using it for quite awhile, I don't think it helps with the ram usage



[-- Attachment #2: Type: text/html, Size: 3107 bytes --]

Re: [gentoo-user] /var/tmp on tmpfs

[Wol's lists]

On 08/02/18 20:56, Grant Taylor wrote:
> On 02/08/2018 10:11 AM, gevisz wrote:
>> And I am going to set the whole /var/tmp on tpmfs instead of just 
>> /var/tmp/portage
>>
>> Is it ok?
> 
> I don't know about the context of emerging, but I do know about the 
> context of /var/tmp being volatile.
> 
> More specifically, /var/tmp is traditionally supposed to be non-volatile 
> (across reboots).
> 
> Comparatively the contents of /tmp can be volatile (across reboots).
> 
> I would advise against mounting /var/tmp on tmpfs.
> 
EMPHATICALLY YES.

/tmp is defined as being volatile - stuff can disappear at any time.

/var/tmp is defined as the place where programs store stuff like crash 
recovery files. Mounting it tmpfs is going to screw up any programs that 
reply on that *defined* behaviour to recover after a crash.

Mounting /var/tmp/portage as tmpfs is perfectly fine as far as I know - 
I do it myself.

Cheers,
Wol

Re: [gentoo-user] /var/tmp on tmpfs

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]

On 02/08/2018 04:18 PM, Wol's lists wrote:
> EMPHATICALLY YES.

;-)

> /tmp is defined as being volatile - stuff can disappear at any time.

I don't know that I've ever had things in /tmp disappear "at any time" 
as in randomly and without external influence.  Usually it's a reboot or 
nightly maintenance scripts cleaning up old (regular) files (as opposed 
to sockets).

> /var/tmp is defined as the place where programs store stuff like crash 
> recovery files. Mounting it tmpfs is going to screw up any programs that 
> reply on that *defined* behaviour to recover after a crash.

Yup.

> Mounting /var/tmp/portage as tmpfs is perfectly fine as far as I know - 
> I do it myself.

I expect that portage, and many other programs, will recover from their 
contents under /var/tmp disappearing in between invocations.  But this 
is something that people need to be aware of.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [gentoo-user] Re: /var/tmp on tmpfs

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]

On 02/08/2018 03:32 PM, gevisz wrote:
> In this case it would be nice to hear a reason.

I think the reason probably goes back a number of years.  When /tmp was 
made volatile (ram / swap backed) there was a need for non-volatile temp 
space.  Thus, /var/tmp was created as non-volatile specifically for the 
purpose to of surviving across reboots.  (At least that's my understanding.)

> That's why I have asked if it does not harm.

I don't think it will actually harm the Operating System.  Some daemons 
may get cross if files they know that they created no longer exist after 
a reboot.

Though things should gracefully handle the absence of such files and 
re-create them.

The biggest Ah Ha moment I ever saw someone have was when they spent 
more than an hour getting a Solaris patch cluster to the machine, 
extracted it to /tmp, rebooted into single user mode, and went where the 
$&#* is the patch cluster?  That's when someone more experienced asked 
them where they put it and got to educate them on the error of their ways.

I doubt that having /var/tmp be volatile will actually break things. 
But it will likely cause unexpected behavior.  IMHO the biggest unknown 
is if you will be caught by or adversely effected by said unknown.

Seeing as how we're talking Linux, Gentoo in specific, you are likely 
power users and configure your systems the way that /you/ want them to 
be.  So, by all means, do what you want.

I just want to give you some data so that you can make an informed decision.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: [gentoo-user] /var/tmp on tmpfs

[Rich Freeman]

On Thu, Feb 8, 2018 at 6:18 PM, Wol's lists <antlists@youngman.org.uk> wrote:
>
> /var/tmp is defined as the place where programs store stuff like crash
> recovery files. Mounting it tmpfs is going to screw up any programs that
> reply on that *defined* behaviour to recover after a crash.
>

Care to cite an example of such a program in the Gentoo repo?  I
certainly can't think of any, and I've been running with /var/tmp on
tmpfs for over a decade.

/var/cache strikes me as a much better place for some kind of recovery
file.  While /var/tmp is typically less volatile than /tmp, it isn't
really something that software should just rely on.

Perhaps FHS says otherwise, but anybody relying on FHS is going to get
burned because lots of distros purge /var/tmp.  The problem with FHS
is that nobody really bothers to try to update it any longer.
Certainly people think twice before deviating it, but they still do
from time to time, usually in the same ways that other distros
deviate.

-- 
Rich

Re: [gentoo-user] /var/tmp on tmpfs

[Wol's lists]

On 09/02/18 00:02, Rich Freeman wrote:
> On Thu, Feb 8, 2018 at 6:18 PM, Wol's lists<antlists@youngman.org.uk>  wrote:
>> /var/tmp is defined as the place where programs store stuff like crash
>> recovery files. Mounting it tmpfs is going to screw up any programs that
>> reply on that*defined*  behaviour to recover after a crash.
>>
> Care to cite an example of such a program in the Gentoo repo?  I
> certainly can't think of any, and I've been running with /var/tmp on
> tmpfs for over a decade.

I don't know of any. I was involved with the LSB ages ago, and they were 
involved with the FHS, and that was just one of the things I picked up - 
the FHS specifically says /var/tmp is for files that are temporary but 
not volatile - files that programs are supposed to clean up behind them 
but are saved if the program is prevented from deleting them.

Cheers,
Wol

Re: [gentoo-user] /var/tmp on tmpfs

[Dale]

Rich Freeman wrote:
> On Thu, Feb 8, 2018 at 2:17 PM, Dale <rdalek1967@gmail.com> wrote:
>> As someone else pointed out, if you
>> start using swap, that generally defeats the purpose of tmpfs.
>>
> I'll just add one thing to this, which I've probably already said ages ago:
>
> In an ideal world swap would STILL be better than building on disk,
> because it gives the kernel fewer constraints around what gets written
> to disk.
>
> Anything written to disk MUST end up on the disk within the dirty
> writeback time limit.  Anything written to tmpfs doesn't ever have to
> end up on disk, and if it is swapped the kernel need not do it in any
> particular timeframe.  Also, the swapfile doesn't need the same kinds
> of integrity features as a filesystem, which probably lowers the cost
> of writes somewhat (if nothing else after a reboot there is no need to
> run tmpreaper on it).
>
> So, swapping SHOULD still be better than building on disk, because any
> object file that doesn't end up being swapped is a saved disk IO, and
> the stuff that does get swapped will hopefully get written at a more
> opportune time vs forcing the kernel to stop what is doing after 30s
> (by default) to make sure that something gets written no matter what
> (if it wasn't deleted before then).
>
> That's all in an ideal world.  In practice I've never found the kernel
> swapping algorithms to be the best in the world, and I've seen a lot
> of situations where it hurts.  I run without a swapfile for this
> reason.  It pains me to do it because I can think of a bunch of
> reasons why this shouldn't help, and yet for whatever reason it does.
>


In my experience, once swap starts getting used, it gets slow, sometimes
to the point that a response may take several seconds or more.  When I
compile without tmpfs at all, which means everything is on disk, it's
rare that I can even tell it is using that IO for the drive.  Every once
in a while I may see a slight delay but not by much.  The worst offender
when I do see it, libreoffice.  As we all know, that is one beast of a
package.  I don't recall having problems with web browsers, yet.  Give
it time tho.  ;-) 

While you may have a point in some situations, here, it just doesn't
work that way.  As we all know tho, even if we all had the same
settings, different systems are going to work differently because of
some difference we may not be aware of.  The mileage will vary for sure. 

I might add, over the years I've changed settings to adapt my system to
give me the best response.  However, if a person built a system with
very little differences hardware and maybe even software wise, they
could still run into something different and want different settings. 
The catch is, take advice from different folks and weigh all the
options, then test things to see what works best.  It may be that one
part of your post helps, another part from mine, another part from
someone else and in the end, it leaves settings that work.  Well, on
that system and for that person at least.  ;-)

Dale

:-)  :-) 

Re: [gentoo-user] Re: /var/tmp on tmpfs

[Dale]

Nikos Chantziaras wrote:
> On 08/02/18 21:17, Dale wrote:
>> I have 16GBs of memory here and have /var/tmp/portage/ on tmpfs, no
>> ccache.  With the growing size of packages, I've had to put several on
>> regular spinning rust to make sure enough space is available.  This is
>> my list, so far.
>>
>> www-client/firefox
>> www-client/seamonkey
>> app-office/libreoffice
>> sys-devel/gcc
>> dev-qt/qtwebengine
>> dev-qt/qtwebkit
>
> I'm on 16GB as well, with a 9GB /var/tmp/portage tmpfs, and all of the
> above build fine. No need to build them on disk.
>
> Note that tmpfs does not consume any memory if there's no files in it!
> So you can make your tmpfs larger. Here, 9GB is enough to build the
> above. However, that's of course for when not using --jobs for
> emering. Just regular -jN in MAKEOPTS.
>
>
> .
>

What I run into a lot, Seamonkey and Firefox has a update at the same
time.  Since they are both fairly large, they end up compiling at the
same time which makes me run short and it fails when it runs out of
space.  So, I just do them on disk and don't worry about it.  That said,
those packages would likely benefit from being done on tmpfs. 

As it is right now, I usually have Seamonkey, multiple profiles of
Firefox running and other programs as well.  Those can easily consume
half of my memory.  While tmpfs doesn't "use" anything when it is not in
use, the other stuff does crowd tmpfs. 

I'm hoping to upgrade to 32GBs of ram at some point.  I could use it for
sure. 

Dale

:-)  :-) 

Re: [gentoo-user] /var/tmp on tmpfs

[Dale]

gevisz wrote:
> 2018-02-08 21:17 GMT+02:00 Dale <rdalek1967@gmail.com>:
>> gevisz wrote:
>>> I never used tmpfs for portage TMPDIR before and now decided to give it a try.
>>>
>>> I have 8GB of RAM and 12GB of swap on a separate partition.
>>>
>>> Do I correctly understood https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs
>>> that I can safely set in the fstab the size of my tmpfs to 12GB so
>>> that the chromium
>>> could be emerged in tmpfs (using the swap) without the need to set notmpfs.conf
>>> for chromium and the likes.
>>>
>>> And I am going to set the whole /var/tmp/ on tpmfs instead of just
>>> /var/tmp/portage
>>> Is it ok?
>> I have 16GBs of memory here and have /var/tmp/portage/ on tmpfs, no
>> ccache.  With the growing size of packages, I've had to put several on
>> regular spinning rust to make sure enough space is available.  This is
>> my list, so far.
>>
>> www-client/firefox
>> www-client/seamonkey
>> app-office/libreoffice
>> sys-devel/gcc
>> dev-qt/qtwebengine
>> dev-qt/qtwebkit
> Thank you for your reply and the notmpfs exception list.
> I think it would be helpfull not only for me.
>
>> Those are the ones that tend to run into space problems.  Keep in mind,
>> I have twice the memory you have.  As someone else pointed out, if you
>> start using swap, that generally defeats the purpose of tmpfs.
>>
>> While I'm sure plenty of packages will make good use of portage being on
>> tmpfs, there will be quite a few that will have space problems.  You
>> will need to be ready to make exceptions for those as they show up but
>> those in my list are certainly ones that you may want to add before
>> trying.  There could be exceptions to this based on your habits and
>> memory requirements for other things but that is my experience so far.
>>
>> Hope that helps.
>>
>> Dale
>>
>> :-)  :-)
>>

You will likely find that you will get some interesting ideas from
several posts and then have to bring them together to work for you. 
Sometimes, you have to mix and match to find what works for you.  If
nothing else, sometimes I post something just in case it may give a
person a light bulb moment with a idea that no one even thought to post,
including me. 

Sometimes just having a start point helps.  Heck, we all started from
nothing when it comes to Gentoo.  Some of us have been around long
enough to learn a lot but forget what we learned.  ROFL 

Dale

:-)  :-) 

Re: [gentoo-user] Re: /var/tmp on tmpfs

[Dale]

gevisz wrote:
>
> You probably will be surprised, but the main reason I am trying to use
> tmpfs for /var/tmp/ is not because I want to make emerging chromium
> faster (I have no hope about that because read somewhere that it will
> make compilation only 10 percent faster) but because I have not too
> much free space on / (sometimes in the past chromium refused to build
> in the similar conditions) and because of that either have to move /var/tmp
> to the separate partition anyway or try to use tmpfs + swap and, if it fails,
> to move to the separate partition only /var/tmp/portage/notmpfs
>


I think you can tell emerge/portage to build that specific program on
another disk.  You just have to tell it where, sort of the same way you
tell it to build on disk instead of tmpfs.  I've never done it but it
should work the same way.  Just make sure the permissions are right. 

My thinking.  Let's say you have chromium that won't fit on the usual
disk.  Tell emerge/portage to build chromium in another directory that
is on another disk. 

/etc/portage/env/largedisk.conf
PORTAGE_TMPDIR="/var/tmp/largedisk"

/etc/portage/package.env/package.env
www-client/chromium  ../env/largedisk.conf

Once you have those files set up to work, then make sure you have your
large disk mounted at /var/tmp/largedisk and I would think it would
work.  Anytime you emerge chromium, it should do that in
/var/tmp/largedisk.  Only question is, do you have another disk to try
this on??? 

Anyone think that wouldn't work???  Basically, you are just telling
emerge/portage to build somewhere else and it shouldn't care where that
is, tmpfs or disk.  Right?

Dale

:-)  :-) 

[gentoo-user] Re: /var/tmp on tmpfs

[Ian Zimmerman]

On 2018-02-09 01:15, Wol's lists wrote:

> > Care to cite an example of such a program in the Gentoo repo?  I
> > certainly can't think of any, and I've been running with /var/tmp on
> > tmpfs for over a decade.
> 
> I don't know of any.

vim?

Although that choice was recently criticized on the oss-security list,
Bram the BDFL seems to be sticking with it.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

Re: [gentoo-user] /var/tmp on tmpfs

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

On Thu, 8 Feb 2018 23:18:19 +0000, Wol's lists wrote:

> > More specifically, /var/tmp is traditionally supposed to be
> > non-volatile (across reboots).
> > 
> > Comparatively the contents of /tmp can be volatile (across reboots).
> > 
> > I would advise against mounting /var/tmp on tmpfs.
> >   
> EMPHATICALLY YES.
> 
> /tmp is defined as being volatile - stuff can disappear at any time.
> 
> /var/tmp is defined as the place where programs store stuff like crash 
> recovery files. Mounting it tmpfs is going to screw up any programs
> that reply on that *defined* behaviour to recover after a crash.
> 
> Mounting /var/tmp/portage as tmpfs is perfectly fine as far as I know - 
> I do it myself.

Why mess around with another tmpfs? Just set PORTAGE_TMPDIR="/tmp" in
make.conf. Job done!


-- 
Neil Bothwick

Why do Kennedy's cry after sex? ..... Mace!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Re: /var/tmp on tmpfs

[gevisz]

2018-02-09 0:50 GMT+02:00 Tsukasa Mcp_Reznor <Mcp_Reznor@hotmail.com>:
> From: freemanrich@gmail.com <freemanrich@gmail.com> on behalf of Rich
> Freeman <rich0@gentoo.org>
> Sent: Thursday, February 8, 2018 5:38 PM
> To: gentoo-user@lists.gentoo.org
> Subject: Re: [gentoo-user] Re: /var/tmp on tmpfs
>
> Just adding my 2 cents EMERGE_DEFAULT_OPTS="--fail-clean" helps
> a ton with tmpfs.

Thank you for the suggestion! Already added it to my make.conf.

> As for the athlon x2 system, consider using distcc, I've been using it for
> quite awhile, I don't think it helps with the ram usage

I am using -march=native in CFLAGS/CXXFLAGS and because of this
reluctant to use distcc, but it is a good idea too.

Re: [gentoo-user] /var/tmp on tmpfs

[Peter Humphrey]

On Friday, 9 February 2018 08:11:29 GMT Neil Bothwick wrote:
> On Thu, 8 Feb 2018 23:18:19 +0000, Wol's lists wrote:
> > > More specifically, /var/tmp is traditionally supposed to be
> > > non-volatile (across reboots).
> > > 
> > > Comparatively the contents of /tmp can be volatile (across reboots).
> > > 
> > > I would advise against mounting /var/tmp on tmpfs.
> > 
> > EMPHATICALLY YES.
> > 
> > /tmp is defined as being volatile - stuff can disappear at any time.
> > 
> > /var/tmp is defined as the place where programs store stuff like crash
> > recovery files. Mounting it tmpfs is going to screw up any programs
> > that reply on that *defined* behaviour to recover after a crash.
> > 
> > Mounting /var/tmp/portage as tmpfs is perfectly fine as far as I know -
> > I do it myself.
> 
> Why mess around with another tmpfs? Just set PORTAGE_TMPDIR="/tmp" in
> make.conf. Job done!

Acting on the advice of various Gentoo guides, I have this:

# grep tmp /etc/fstab
tmpfs           /var/tmp/portage        tmpfs   noatime,uid=portage,gid=portage,mode=0775  0 0
tmpfs           /tmp                    tmpfs   noatime,nosuid,nodev,noexec,mode=1777   0 0

Are you saying I don't gain anything from it?

-- 
Regards,
Peter.

Re: [gentoo-user] /var/tmp on tmpfs

[gevisz]

2018-02-09 10:11 GMT+02:00 Neil Bothwick <neil@digimed.co.uk>:
> On Thu, 8 Feb 2018 23:18:19 +0000, Wol's lists wrote:
>
>> > More specifically, /var/tmp is traditionally supposed to be
>> > non-volatile (across reboots).
>> >
>> > Comparatively the contents of /tmp can be volatile (across reboots).
>> >
>> > I would advise against mounting /var/tmp on tmpfs.
>> >
>> EMPHATICALLY YES.
>>
>> /tmp is defined as being volatile - stuff can disappear at any time.
>>
>> /var/tmp is defined as the place where programs store stuff like crash
>> recovery files. Mounting it tmpfs is going to screw up any programs
>> that reply on that *defined* behaviour to recover after a crash.
>>
>> Mounting /var/tmp/portage as tmpfs is perfectly fine as far as I know -
>> I do it myself.
>
> Why mess around with another tmpfs? Just set PORTAGE_TMPDIR="/tmp" in
> make.conf. Job done!

It is an interesting idea. But why it is not done by default then?

Can somebody think of a situation when it should not be done?

My /tmp is not on tmpfs currently. Only /run

May be, it is not a good idea to put /mnt on tmpfs at the time of
Spector and Meltdown?

Re: [gentoo-user] /var/tmp on tmpfs

[gevisz]

2018-02-09 3:24 GMT+02:00 Dale <rdalek1967@gmail.com>:
>
> In my experience, once swap starts getting used, it gets slow, sometimes
> to the point that a response may take several seconds or more.  When I
> compile without tmpfs at all, which means everything is on disk, it's
> rare that I can even tell it is using that IO for the drive.

Thank you for the information. It is always good to know the downside
of your decision. In this case, of using the swap.

So far, I never saw my swap busy, even when running VirtualBox with
half of my RAM assigned to it.

> The catch is, take advice from different folks and weigh all the
> options, then test things to see what works best.  It may be that one
> part of your post helps, another part from mine, another part from
> someone else and in the end, it leaves settings that work.  Well, on
> that system and for that person at least.  ;-)

Yes. I am greatfull to all who wrote to this thread. :)

Re: [gentoo-user] /var/tmp on tmpfs

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

On Fri, 9 Feb 2018 12:30:21 +0200, gevisz wrote:

> > Why mess around with another tmpfs? Just set PORTAGE_TMPDIR="/tmp" in
> > make.conf. Job done!  
> 
> It is an interesting idea. But why it is not done by default then?
> 
Because when the defaults were picked neither /tmp nor /var/tmp used
tmpfs but /tmp was cleared at boot. Some of the default for portage are
curious, to say the least, like using /usr for dynamic data.


-- 
Neil Bothwick

667 - The FAX number of the beast

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] /var/tmp on tmpfs

[Gerrit Kühn]

On Fri, 9 Feb 2018 12:30:21 +0200 gevisz <gevisz@gmail.com> wrote about
Re: [gentoo-user] /var/tmp on tmpfs:

> > Why mess around with another tmpfs? Just set PORTAGE_TMPDIR="/tmp" in
> > make.conf. Job done!
> 
> It is an interesting idea. But why it is not done by default then?
> 
> Can somebody think of a situation when it should not be done?

/var/tmp/portage may take up quite some space, and not everybody will want
to have that on a RAM-based fs.


cu
  Gerrit

Re: [gentoo-user] /var/tmp on tmpfs

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

On Fri, 09 Feb 2018 10:12:01 +0000, Peter Humphrey wrote:

> > Why mess around with another tmpfs? Just set PORTAGE_TMPDIR="/tmp" in
> > make.conf. Job done!  
> 
> Acting on the advice of various Gentoo guides, I have this:
> 
> # grep tmp /etc/fstab
> tmpfs           /var/tmp/portage        tmpfs
> noatime,uid=portage,gid=portage,mode=0775  0 0
> tmpfs           /tmp                    tmpfs
> noatime,nosuid,nodev,noexec,mode=1777   0 0
> 
> Are you saying I don't gain anything from it?

I can't see any benefit from the added complexity. If you want portage to
use a tmpfs for its temporary directory, why not use one that is already
there?


-- 
Neil Bothwick

Fragile. Do not turn umop ap1sdn!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Re: /var/tmp on tmpfs

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 415 bytes --]

On Thu, 8 Feb 2018 22:50:58 +0000, Tsukasa Mcp_Reznor wrote:

> Just adding my 2 cents EMERGE_DEFAULT_OPTS="--fail-clean" helps a ton
> with tmpfs.

But it doesn't help much when your chromium build fails with 30 minutes to
go and a quick(ish) "ebuild path/to/ebuild merge" would have fixed it, as
has happened to me a few times recently :(


-- 
Neil Bothwick

Top Oxymorons Number 4: Diet ice cream

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Re: /var/tmp on tmpfs

[gevisz]

2018-02-09 3:50 GMT+02:00 Dale <rdalek1967@gmail.com>:
> gevisz wrote:
>>
>> You probably will be surprised, but the main reason I am trying to use
>> tmpfs for /var/tmp/ is not because I want to make emerging chromium
>> faster (I have no hope about that because read somewhere that it will
>> make compilation only 10 percent faster) but because I have not too
>> much free space on / (sometimes in the past chromium refused to build
>> in the similar conditions) and because of that either have to move /var/tmp
>> to the separate partition anyway or try to use tmpfs + swap and, if it fails,
>> to move to the separate partition only /var/tmp/portage/notmpfs
>>
>
>
> I think you can tell emerge/portage to build that specific program on
> another disk.  You just have to tell it where, sort of the same way you
> tell it to build on disk instead of tmpfs.  I've never done it but it
> should work the same way.  Just make sure the permissions are right.
>
> My thinking.  Let's say you have chromium that won't fit on the usual
> disk.  Tell emerge/portage to build chromium in another directory that
> is on another disk.
>
> /etc/portage/env/largedisk.conf
> PORTAGE_TMPDIR="/var/tmp/largedisk"
>
> /etc/portage/package.env/package.env
> www-client/chromium  ../env/largedisk.conf
>
> Once you have those files set up to work, then make sure you have your
> large disk mounted at /var/tmp/largedisk and I would think it would
> work.  Anytime you emerge chromium, it should do that in
> /var/tmp/largedisk.  Only question is, do you have another disk to try
> this on???

Yes. I still have an unused 4th primary partition on the same hard disk.
I am going to make it extended and create 3 more partitions on it:
one — for /var/tmp/notmfs, another — for /var/log and the 3rd one —
for some unpredictable purposes like installing a rescue system.
Still have not decided on their size, file system and mount options
but it would be another question in a separate thread, when I come to it.

I am currently building a new and shiny :) Gentoo system on the
1st primery partion of this disk, that actually contained old /var/tmp,
because I am a bit afraid to update my old and still working Gentoo
system on the same hard disk that I have not updated for about 9 months.

Moreover, I have changed profile from not used for a long time
default/linux/amd64/13.0/desktop/gnome
one to
default/linux/amd64/17.0/desktop/
and already found out a lot of not wise solutions like alsa + pulseaudio
with initrc and the likes that I currently trying to avoid.

> Anyone think that wouldn't work???  Basically, you are just telling
> emerge/portage to build somewhere else and it shouldn't care where that
> is, tmpfs or disk.  Right?

It is exactly what suggested in the "Per-package choices at compile time"
section of the "Portage TMPDIR on tmpfs” Gentoo wiki. So it should work. :)

Re: [gentoo-user] Re: /var/tmp on tmpfs

[gevisz]

2018-02-09 4:15 GMT+02:00 Ian Zimmerman <itz@very.loosely.org>:
> On 2018-02-09 01:15, Wol's lists wrote:
>
>> > Care to cite an example of such a program in the Gentoo repo?  I
>> > certainly can't think of any, and I've been running with /var/tmp on
>> > tmpfs for over a decade.
>>
>> I don't know of any.
>
> vim?
>
> Although that choice was recently criticized on the oss-security list,
> Bram the BDFL seems to be sticking with it.

Ok, thank you for the information.

You have convinced me to stick with the standard. :)

Re: [gentoo-user] /var/tmp on tmpfs

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]

On 02/09/2018 03:30 AM, gevisz wrote:
> May be, it is not a good idea to put /mnt on tmpfs at the time of Spector 
> and Meltdown?

I wouldn't put /mnt on tmpfs as I routinely create mount points there 
in.  As such they would be lost on reboot.

What difference does Spector or Meltdown (or the next big security 
thing) have on using tmpfs for /mnt or not?



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

[gentoo-user] Re: /var/tmp on tmpfs

[Kai Krakow]

Am Thu, 08 Feb 2018 19:11:48 +0200 schrieb gevisz:

> I never used tmpfs for portage TMPDIR before and now decided to give it
> a try.
> 
> I have 8GB of RAM and 12GB of swap on a separate partition.
> 
> Do I correctly understood
> https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs that I can safely
> set in the fstab the size of my tmpfs to 12GB so that the chromium could
> be emerged in tmpfs (using the swap) without the need to set
> notmpfs.conf for chromium and the likes.
> 
> And I am going to set the whole /var/tmp/ on tpmfs instead of just
> /var/tmp/portage Is it ok?

I'm using systemd automounts to discard /var/tmp/portage when there is no
longer a user of this directory. It has one caveat: If you want to
inspect build problems, you should keep a shell running inside.

Here's the configuration:

$ fgrep portage /etc/fstab
none /var/tmp/portage tmpfs noauto,size=150%,uid=250,gid=250,mode=0775,x-systemd.automount 0 0

$ cat /etc/tmpfiles.d/portage.conf
D /var/tmp/portage 0775 portage portage
x /var/tmp/portage

I used ccache before but building in tmpfs is much faster.

I'm currently experimenting with tuning vm.watermark_scaling_factor as the
kernel tends to swap storms with very high desktop latencies during package
builds which consume a lot of tmpfs. This is behavior I'm seeing since
kernel 4.9, worked better before.

As such, I think it makes most sense to put only /var/tmp/portage on tmpfs.
Programs may expect /var/tmp as being non-volatile over reboots.


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: /var/tmp on tmpfs

[Kai Krakow]

Am Thu, 08 Feb 2018 16:42:23 -0700 schrieb Grant Taylor:

> On 02/08/2018 03:32 PM, gevisz wrote:
>> In this case it would be nice to hear a reason.
> 
> I think the reason probably goes back a number of years.  When /tmp was
> made volatile (ram / swap backed) there was a need for non-volatile temp
> space.  Thus, /var/tmp was created as non-volatile specifically for the
> purpose to of surviving across reboots.  (At least that's my
> understanding.)

I don't think this is the reason. Both directories have been there since 
ages, long before someone even considered putting that into ram disks. 
Historically, there would even be /usr/tmp.

The point here is that /var is "variable" data in contrast to "read-only" 
data on the other partitions. This makes /var a candidate for persistent 
OS-state. You could simply keep / and /usr on volatile storage (or even 
read-only storage) and all your variable, non-volatile data would be in
/var.

Having /tmp on tmpfs is then a logical consequence of this because / 
could be read-only. Also, /etc should be symlinked to /var/etc to enable 
and keep configuration changes over reboots, although this could also be 
populated by a boot-strapping process (e.g., IP configuration).

This is especially interesting for container-based, dynamic cloud servers 
which would spawn and disappear on demand, you just need to keep the non-
volatile state directory /var. Usually, such systems start with an empty
/etc directory which is populated by a boot-strapping process.

Following that idea, /var/tmp should also be non-volatile.

Bringing this idea further forward, everything related to the OS-image 
should move to /usr (catchword "usrmerge"), and then / which contains
/var and /etc could be writeable and non-volatile, /usr would contain
boot-strapping configuration and be read-only, /etc would be populated on 
first boot. The idea of /tmp on tmpfs is just kept here.

The idea of having everything boot-related in / doesn't apply since years 
(and wasn't the original idea anyways). These days, initramfs takes this 
role and /usr takes the role of /, and /home already took the role of /usr 
(that's why it's called /usr, it was user data in early unix). The 
splitting we have today is a result of size-constraints of early systems 
when the OS no longer fit one disk, when / became the early boot-
environment (initramfs today). Today, the OS uses dynamic linking when 
most of it was statically linked in the early day, and thus there are 
dependencies between / and /usr that cannot be untangled easily, and 
renders the split for early boot-environments difficult to maintain. So 
everything might easily move to /usr and / can become a non-volatile 
state partition containing /var and /etc. And early boot lives in 
initramfs (to setup /usr mount).


>> That's why I have asked if it does not harm.
> 
> I don't think it will actually harm the Operating System.  Some daemons
> may get cross if files they know that they created no longer exist after
> a reboot.
> 
> Though things should gracefully handle the absence of such files and
> re-create them.
> 
> The biggest Ah Ha moment I ever saw someone have was when they spent
> more than an hour getting a Solaris patch cluster to the machine,
> extracted it to /tmp, rebooted into single user mode, and went where the
> $&#* is the patch cluster?  That's when someone more experienced asked
> them where they put it and got to educate them on the error of their
> ways.
> 
> I doubt that having /var/tmp be volatile will actually break things.

Usually not but it might be interesting to have it non-volatile in the 
scenario I described above: Something which survives the complete machine 
being discarded (except it's state) and then later boot-strapped again on 
demand.


> But it will likely cause unexpected behavior.  IMHO the biggest unknown
> is if you will be caught by or adversely effected by said unknown.
> 
> Seeing as how we're talking Linux, Gentoo in specific, you are likely
> power users and configure your systems the way that /you/ want them to
> be.  So, by all means, do what you want.
> 
> I just want to give you some data so that you can make an informed
> decision.

It's all a question of where you want to go. And having at least a 
minimum set of guarantees is important here. Otherwise no one is able to 
setup a system the way they want. Because if semantics change later you 
will upset one or another person.

One example of this is having /usr split and / as early boot-environment: 
It never gave that guarantee due to dynamic linking (it could not) which 
led to inventions like initramfs.


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: /var/tmp on tmpfs

[Kai Krakow]

Am Thu, 08 Feb 2018 14:50:31 -0500 schrieb Rich Freeman:

> On Thu, Feb 8, 2018 at 2:17 PM, Dale <rdalek1967@gmail.com> wrote:
>> As someone else pointed out, if you start using swap, that generally
>> defeats the purpose of tmpfs.
>>
>>
> I'll just add one thing to this, which I've probably already said ages
> ago:
> 
> In an ideal world swap would STILL be better than building on disk,
> because it gives the kernel fewer constraints around what gets written
> to disk.
> 
> Anything written to disk MUST end up on the disk within the dirty
> writeback time limit.  Anything written to tmpfs doesn't ever have to
> end up on disk, and if it is swapped the kernel need not do it in any
> particular timeframe.  Also, the swapfile doesn't need the same kinds of
> integrity features as a filesystem, which probably lowers the cost of
> writes somewhat (if nothing else after a reboot there is no need to run
> tmpreaper on it).
> 
> So, swapping SHOULD still be better than building on disk, because any
> object file that doesn't end up being swapped is a saved disk IO, and
> the stuff that does get swapped will hopefully get written at a more
> opportune time vs forcing the kernel to stop what is doing after 30s (by
> default) to make sure that something gets written no matter what (if it
> wasn't deleted before then).

I can only second this.

> That's all in an ideal world.  In practice I've never found the kernel
> swapping algorithms to be the best in the world, and I've seen a lot of
> situations where it hurts.  I run without a swapfile for this reason. 
> It pains me to do it because I can think of a bunch of reasons why this
> shouldn't help, and yet for whatever reason it does.

I really prefer having inactive things being swapped out than discarding 
cache from memory. But since kernel 4.9 this no longer works so well. I'm 
still seeking the reason. But for that reason, building in tmpfs is no 
longer such an appealing option as before.

Otherwise, I was quite happy with swap behavior, exactly for the reasons 
you initially outlined.


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: /var/tmp on tmpfs

[Kai Krakow]

Am Fri, 09 Feb 2018 10:58:35 +0000 schrieb Neil Bothwick:

> On Fri, 09 Feb 2018 10:12:01 +0000, Peter Humphrey wrote:
> 
>> > Why mess around with another tmpfs? Just set PORTAGE_TMPDIR="/tmp" in
>> > make.conf. Job done!
>> 
>> Acting on the advice of various Gentoo guides, I have this:
>> 
>> # grep tmp /etc/fstab tmpfs           /var/tmp/portage        tmpfs
>> noatime,uid=portage,gid=portage,mode=0775  0 0 tmpfs           /tmp    
>>                tmpfs noatime,nosuid,nodev,noexec,mode=1777   0 0
>> 
>> Are you saying I don't gain anything from it?
> 
> I can't see any benefit from the added complexity. If you want portage
> to use a tmpfs for its temporary directory, why not use one that is
> already there?

The point here is having /tmp as noexec. That's not exactly what I'd call 
added complexity.


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: /var/tmp on tmpfs

[Kai Krakow]

Am Fri, 09 Feb 2018 12:30:21 +0200 schrieb gevisz:

> 2018-02-09 10:11 GMT+02:00 Neil Bothwick <neil@digimed.co.uk>:
>> On Thu, 8 Feb 2018 23:18:19 +0000, Wol's lists wrote:
>>
>>> > More specifically, /var/tmp is traditionally supposed to be
>>> > non-volatile (across reboots).
>>> >
>>> > Comparatively the contents of /tmp can be volatile (across reboots).
>>> >
>>> > I would advise against mounting /var/tmp on tmpfs.
>>> >
>>> EMPHATICALLY YES.
>>>
>>> /tmp is defined as being volatile - stuff can disappear at any time.
>>>
>>> /var/tmp is defined as the place where programs store stuff like crash
>>> recovery files. Mounting it tmpfs is going to screw up any programs
>>> that reply on that *defined* behaviour to recover after a crash.
>>>
>>> Mounting /var/tmp/portage as tmpfs is perfectly fine as far as I know
>>> -
>>> I do it myself.
>>
>> Why mess around with another tmpfs? Just set PORTAGE_TMPDIR="/tmp" in
>> make.conf. Job done!
> 
> It is an interesting idea. But why it is not done by default then?
> 
> Can somebody think of a situation when it should not be done?
> 
> My /tmp is not on tmpfs currently. Only /run
> 
> May be, it is not a good idea to put /mnt on tmpfs at the time of
> Spector and Meltdown?

Portage doesn't run off /tmp by default because general recommendation is 
to mount /tmp with noexec. Build scripts won't be able to run that way.


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: /var/tmp on tmpfs

[Kai Krakow]

Am Thu, 08 Feb 2018 19:02:10 -0500 schrieb Rich Freeman:

> On Thu, Feb 8, 2018 at 6:18 PM, Wol's lists <antlists@youngman.org.uk>
> wrote:
>>
>> /var/tmp is defined as the place where programs store stuff like crash
>> recovery files. Mounting it tmpfs is going to screw up any programs
>> that reply on that *defined* behaviour to recover after a crash.
>>
>>
> Care to cite an example of such a program in the Gentoo repo?  I
> certainly can't think of any, and I've been running with /var/tmp on
> tmpfs for over a decade.
> 
> /var/cache strikes me as a much better place for some kind of recovery
> file.  While /var/tmp is typically less volatile than /tmp, it isn't
> really something that software should just rely on.

I don't think that /var/cache is a better choice here. Cache directories 
should be treated as data that could be rebuilt at ANY time. That's 
certainly not true for crash dump files. They simply don't belong there.

Thus, crash dumps should go to non-volatile directories like /var/tmp.


-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: /var/tmp on tmpfs

[Wols Lists]

On 10/02/18 18:56, Kai Krakow wrote:
> role and /usr takes the role of /, and /home already took the role of /usr 
> (that's why it's called /usr, it was user data in early unix). The 

Actually no, not at all. /usr is not short for USeR, it's an acronym for
User System Resources, which is why it contains OS stuff, not user
stuff. Very confusing, I know.

Cheers,
Wol

[gentoo-user] Re: /var/tmp on tmpfs

[Kai Krakow]

Am Sat, 10 Feb 2018 19:38:56 +0000 schrieb Wols Lists:

> On 10/02/18 18:56, Kai Krakow wrote:
>> role and /usr takes the role of /, and /home already took the role of
>> /usr (that's why it's called /usr, it was user data in early unix). The
> 
> Actually no, not at all. /usr is not short for USeR, it's an acronym for
> User System Resources, which is why it contains OS stuff, not user
> stuff. Very confusing, I know.

From https://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html:

> In the original Unix implementations, /usr was where the home
> directories of the users were placed (that is to say, /usr/someone was 
> then the directory now known as /home/someone). In current Unices, /usr 
> is where user-land programs and data (as opposed to 'system land'
> programs and data) are. The name hasn't changed, but it's meaning has 
> narrowed and lengthened from "everything user related" to "user usable 
> programs and data". As such, some people may now refer to this 
> directory as meaning 'User System Resources' and not 'user' as was 
> originally intended.

So, actually the acronym was only invented later to represent the new 
role of the directory. ;-)


-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: /var/tmp on tmpfs

[Rich Freeman]

On Sat, Feb 10, 2018 at 2:52 PM, Kai Krakow <hurikhan77@gmail.com> wrote:
> Am Sat, 10 Feb 2018 19:38:56 +0000 schrieb Wols Lists:
>
>> On 10/02/18 18:56, Kai Krakow wrote:
>>> role and /usr takes the role of /, and /home already took the role of
>>> /usr (that's why it's called /usr, it was user data in early unix). The
>>
>> Actually no, not at all. /usr is not short for USeR, it's an acronym for
>> User System Resources, which is why it contains OS stuff, not user
>> stuff. Very confusing, I know.
>
> From https://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html:
>
>> In the original Unix implementations, /usr was where the home
>> directories of the users were placed (that is to say, /usr/someone was
>> then the directory now known as /home/someone). In current Unices, /usr
>> is where user-land programs and data (as opposed to 'system land'
>> programs and data) are. The name hasn't changed, but it's meaning has
>> narrowed and lengthened from "everything user related" to "user usable
>> programs and data". As such, some people may now refer to this
>> directory as meaning 'User System Resources' and not 'user' as was
>> originally intended.
>
> So, actually the acronym was only invented later to represent the new
> role of the directory. ;-)
>

A bit more of history here:

http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split

-- 
Rich

[gentoo-user] Re: /var/tmp on tmpfs

[Kai Krakow]

Am Sat, 10 Feb 2018 15:06:06 -0500 schrieb Rich Freeman:

> On Sat, Feb 10, 2018 at 2:52 PM, Kai Krakow <hurikhan77@gmail.com>
> wrote:
>> Am Sat, 10 Feb 2018 19:38:56 +0000 schrieb Wols Lists:
>>
>>> On 10/02/18 18:56, Kai Krakow wrote:
>>>> role and /usr takes the role of /, and /home already took the role of
>>>> /usr (that's why it's called /usr, it was user data in early unix).
>>>> The
>>>
>>> Actually no, not at all. /usr is not short for USeR, it's an acronym
>>> for User System Resources, which is why it contains OS stuff, not user
>>> stuff. Very confusing, I know.
>>
>> From https://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html:
>>
>>> In the original Unix implementations, /usr was where the home
>>> directories of the users were placed (that is to say, /usr/someone was
>>> then the directory now known as /home/someone). In current Unices,
>>> /usr is where user-land programs and data (as opposed to 'system land'
>>> programs and data) are. The name hasn't changed, but it's meaning has
>>> narrowed and lengthened from "everything user related" to "user usable
>>> programs and data". As such, some people may now refer to this
>>> directory as meaning 'User System Resources' and not 'user' as was
>>> originally intended.
>>
>> So, actually the acronym was only invented later to represent the new
>> role of the directory. ;-)
>>
>>
> A bit more of history here:
> 
> http://www.osnews.com/story/25556/
Understanding_the_bin_sbin_usr_bin_usr_sbin_Split

Thanks, nice reading.

I'm looking forward to Gentoo usrmerge. While supported with 17.1 
profile, I just don't want to try. There's probably lots of bugs around 
in packages.

Although it's tempting to just symlink /bin /sbin /lib* to their /usr 
counterparts.


-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: /var/tmp on tmpfs

[Wol's lists]

On 10/02/18 20:06, Rich Freeman wrote:
> On Sat, Feb 10, 2018 at 2:52 PM, Kai Krakow <hurikhan77@gmail.com> wrote:
>> Am Sat, 10 Feb 2018 19:38:56 +0000 schrieb Wols Lists:
>>
>>> On 10/02/18 18:56, Kai Krakow wrote:
>>>> role and /usr takes the role of /, and /home already took the role of
>>>> /usr (that's why it's called /usr, it was user data in early unix). The
>>>
>>> Actually no, not at all. /usr is not short for USeR, it's an acronym for
>>> User System Resources, which is why it contains OS stuff, not user
>>> stuff. Very confusing, I know.
>>
>>  From https://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html:
>>
>>> In the original Unix implementations, /usr was where the home
>>> directories of the users were placed (that is to say, /usr/someone was
>>> then the directory now known as /home/someone). In current Unices, /usr
>>> is where user-land programs and data (as opposed to 'system land'
>>> programs and data) are. The name hasn't changed, but it's meaning has
>>> narrowed and lengthened from "everything user related" to "user usable
>>> programs and data". As such, some people may now refer to this
>>> directory as meaning 'User System Resources' and not 'user' as was
>>> originally intended.
>>
>> So, actually the acronym was only invented later to represent the new
>> role of the directory. ;-)
>>
> 
> A bit more of history here:
> 
> http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split
> 
Fascinating. And I made a typo, which is interesting too - I always knew 
it as Unix System Resources - typing "user" was a mistake ... I wonder 
how much weird info is down to mistakes like that :-)

Cheers,
Wol

[gentoo-user] Re: /var/tmp on tmpfs

[Kai Krakow]

Am Sat, 10 Feb 2018 21:20:16 +0000 schrieb Wol's lists:

> On 10/02/18 20:06, Rich Freeman wrote:
>> On Sat, Feb 10, 2018 at 2:52 PM, Kai Krakow <hurikhan77@gmail.com>
>> wrote:
>>> Am Sat, 10 Feb 2018 19:38:56 +0000 schrieb Wols Lists:
>>>
>>>> On 10/02/18 18:56, Kai Krakow wrote:
>>>>> role and /usr takes the role of /, and /home already took the role
>>>>> of /usr (that's why it's called /usr, it was user data in early
>>>>> unix). The
>>>>
>>>> Actually no, not at all. /usr is not short for USeR, it's an acronym
>>>> for User System Resources, which is why it contains OS stuff, not
>>>> user stuff. Very confusing, I know.
>>>
>>>  From
>>>  https://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html:
>>>
>>>> In the original Unix implementations, /usr was where the home
>>>> directories of the users were placed (that is to say, /usr/someone
>>>> was then the directory now known as /home/someone). In current
>>>> Unices, /usr is where user-land programs and data (as opposed to
>>>> 'system land' programs and data) are. The name hasn't changed, but
>>>> it's meaning has narrowed and lengthened from "everything user
>>>> related" to "user usable programs and data". As such, some people may
>>>> now refer to this directory as meaning 'User System Resources' and
>>>> not 'user' as was originally intended.
>>>
>>> So, actually the acronym was only invented later to represent the new
>>> role of the directory. ;-)
>>>
>>>
>> A bit more of history here:
>> 
>> http://www.osnews.com/story/25556/
Understanding_the_bin_sbin_usr_bin_usr_sbin_Split
>> 
> Fascinating. And I made a typo, which is interesting too - I always knew
> it as Unix System Resources - typing "user" was a mistake ... I wonder
> how much weird info is down to mistakes like that :-)

You should trust your hidden secret skills more... :-D


-- 
Regards,
Kai

Replies to list-only preferred.