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

[Kai Krakow]

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

> On 10/02/18 20:06, Rich Freeman wrote:
>> On Sat, Feb 10, 2018 at 2:52 PM, Kai Krakow 
>> wrote:
>>> Am Sat, 10 Feb 2018 19:38:56 + 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.

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  wrote:

Am Sat, 10 Feb 2018 19:38:56 + 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 15:06:06 -0500 schrieb Rich Freeman:

> On Sat, Feb 10, 2018 at 2:52 PM, Kai Krakow 
> wrote:
>> Am Sat, 10 Feb 2018 19:38:56 + 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

[Rich Freeman]

On Sat, Feb 10, 2018 at 2:52 PM, Kai Krakow  wrote:
> Am Sat, 10 Feb 2018 19:38:56 + 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 19:38:56 + 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

[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 Thu, 08 Feb 2018 19:02:10 -0500 schrieb Rich Freeman:

> On Thu, Feb 8, 2018 at 6:18 PM, Wol's lists 
> 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.

[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 :
>> On Thu, 8 Feb 2018 23:18:19 +, 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 Fri, 09 Feb 2018 10:58:35 + schrieb Neil Bothwick:

> On Fri, 09 Feb 2018 10:12:01 +, 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/portagetmpfs
>> 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 Thu, 08 Feb 2018 14:50:31 -0500 schrieb Rich Freeman:

> On Thu, Feb 8, 2018 at 2:17 PM, Dale  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 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
> 

[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.

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

[gevisz]

2018-02-09 4:15 GMT+02:00 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.

Ok, thank you for the information.

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

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

[gevisz]

2018-02-09 3:50 GMT+02:00 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???

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

[Neil Bothwick]

On Thu, 8 Feb 2018 22:50:58 +, 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


pgpm6zcGQni4J.pgp
Description: OpenPGP digital signature

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

[gevisz]

2018-02-09 0:50 GMT+02:00 Tsukasa Mcp_Reznor <mcp_rez...@hotmail.com>:
> From: freemanr...@gmail.com <freemanr...@gmail.com> on behalf of Rich
> Freeman <ri...@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.

[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] 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

:-)  :-) 

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] Re: /var/tmp on tmpfs

[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.)



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 
$

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

[Tsukasa Mcp_Reznor]

From: freemanr...@gmail.com <freemanr...@gmail.com> on behalf of Rich Freeman 
<ri...@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 <gev...@gmail.com> wrote:
>> 2018-02-09 0:19 GMT+02:00 Nikos Chantziaras <rea...@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

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

[Rich Freeman]

On Thu, Feb 8, 2018 at 5:32 PM, gevisz  wrote:
> 2018-02-09 0:19 GMT+02:00 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.
>
> 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

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

[gevisz]

2018-02-09 0:19 GMT+02:00 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.

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: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-08 23:57 GMT+02:00 Rich Freeman :
> On Thu, Feb 8, 2018 at 4:52 PM, gevisz  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.

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

[Rich Freeman]

On Thu, Feb 8, 2018 at 4:52 PM, gevisz  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] Re: /var/tmp on tmpfs

[gevisz]

2018-02-08 20:13 GMT+02:00 Rich Freeman :
> 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

[gevisz]

2018-02-08 19:47 GMT+02:00 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.

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

[Rich Freeman]

On Thu, Feb 8, 2018 at 2:05 PM, Nikos Chantziaras  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

[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.

[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] Re: /var/tmp on tmpfs

[Rich Freeman]

On Thu, Feb 8, 2018 at 12:47 PM, Nikos Chantziaras  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 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.)