[gentoo-user] How can I control size of /run (tmpfs)?

[gentoo-user] How can I control size of /run (tmpfs)?

[Jarry]

Hi,

after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted
as tmpfs. But I can not find any mount-option for controlling
how much memory is (or could be) used for it.

Filesystem     1K-blocks    Used Available Use% Mounted on
tmpfs            8223848     224   8223624   1% /run

I know it does not use 8GB right now, yet I'd like to reduce
it to some lower value, not half of my physical memory.
How can I do it? Can I simply add line in fstab like:

none /run tmpfs size=128m 0 0         ???

Jarry
-- 
_______________________________________________________________
This mailbox accepts e-mails only from selected mailing-lists!
Everything else is considered to be spam and therefore deleted.

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Dale]

Jarry wrote:
> Hi,
> 
> after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted
> as tmpfs. But I can not find any mount-option for controlling
> how much memory is (or could be) used for it.
> 
> Filesystem     1K-blocks    Used Available Use% Mounted on
> tmpfs            8223848     224   8223624   1% /run
> 
> I know it does not use 8GB right now, yet I'd like to reduce
> it to some lower value, not half of my physical memory.
> How can I do it? Can I simply add line in fstab like:
> 
> none /run tmpfs size=128m 0 0         ???
> 
> Jarry


Holy smoke !  Mine is doing the same thing.

tmpfs                   7.9G  260K  7.9G   1% /run

But I also have this:

tmpfs                   7.9G     0  7.9G   0% /var/tmp/portage

So, between those two, I could run out of ram since I have 16Gbs.

There is now TWO people that needs a answer to this question.  Why does
it need that much anyway?  It looks to me like a few hundred Mbs, like
Jarry posted, would be plenty.  Jeepers creepers.  lol

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Jarry]

On 26-May-12 22:01, Dale wrote:
> Jarry wrote:
>>
>> after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted
>> as tmpfs. But I can not find any mount-option for controlling
>> how much memory is (or could be) used for it.
>>
>> Filesystem     1K-blocks    Used Available Use% Mounted on
>> tmpfs            8223848     224   8223624   1% /run
>>
>> I know it does not use 8GB right now, yet I'd like to reduce
>> it to some lower value, not half of my physical memory.
>> How can I do it? Can I simply add line in fstab like:
>>
>> none /run tmpfs size=128m 0 0         ???
>>
>> Jarry
>
> Holy smoke !  Mine is doing the same thing.
> tmpfs                   7.9G  260K  7.9G   1% /run
>
> But I also have this:
> tmpfs                   7.9G     0  7.9G   0% /var/tmp/portage
>
> So, between those two, I could run out of ram since I have 16Gbs.
>
> There is now TWO people that needs a answer to this question.  Why does
> it need that much anyway?  It looks to me like a few hundred Mbs, like
> Jarry posted, would be plenty.  Jeepers creepers.  lol
>
> Dale

I suppose default size for tmpfs is half of physical memory,
if it is not configured somewhere else.

BTW, is there any way to turn this great feature off?
What is it good for? I do not see any advantage in having
/run on tmpfs...

Jarry
-- 
_______________________________________________________________
This mailbox accepts e-mails only from selected mailing-lists!
Everything else is considered to be spam and therefore deleted.

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Dale]

Jarry wrote:
> On 26-May-12 22:01, Dale wrote:
>> Jarry wrote:
>>>
>>> after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted
>>> as tmpfs. But I can not find any mount-option for controlling
>>> how much memory is (or could be) used for it.
>>>
>>> Filesystem     1K-blocks    Used Available Use% Mounted on
>>> tmpfs            8223848     224   8223624   1% /run
>>>
>>> I know it does not use 8GB right now, yet I'd like to reduce
>>> it to some lower value, not half of my physical memory.
>>> How can I do it? Can I simply add line in fstab like:
>>>
>>> none /run tmpfs size=128m 0 0         ???
>>>
>>> Jarry
>>
>> Holy smoke !  Mine is doing the same thing.
>> tmpfs                   7.9G  260K  7.9G   1% /run
>>
>> But I also have this:
>> tmpfs                   7.9G     0  7.9G   0% /var/tmp/portage
>>
>> So, between those two, I could run out of ram since I have 16Gbs.
>>
>> There is now TWO people that needs a answer to this question.  Why does
>> it need that much anyway?  It looks to me like a few hundred Mbs, like
>> Jarry posted, would be plenty.  Jeepers creepers.  lol
>>
>> Dale
> 
> I suppose default size for tmpfs is half of physical memory,
> if it is not configured somewhere else.
> 
> BTW, is there any way to turn this great feature off?
> What is it good for? I do not see any advantage in having
> /run on tmpfs...
> 
> Jarry


I had no idea it was doing this either until your post.  I got the same
questions as you do.  Why is it there?  Why so much is allocated to it?
 Where can we change the settings for this questionable "feature"?

I'm hoping someone will come along and answer both our questions.  I'm
really hoping for a place we can change the settings.  I don't mind it
being there so much if it is useful.   I would like to know its purpose
tho.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Michael Mol]

On Sat, May 26, 2012 at 8:08 PM, Jarry <mr.jarry@gmail.com> wrote:
> On 26-May-12 22:01, Dale wrote:
>
>> Jarry wrote:
>>>
>>>
>>> after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted
>>> as tmpfs. But I can not find any mount-option for controlling
>>> how much memory is (or could be) used for it.
>>>
>>> Filesystem     1K-blocks    Used Available Use% Mounted on
>>> tmpfs            8223848     224 8223624   1% /run
>>>
>>> I know it does not use 8GB right now, yet I'd like to reduce
>>> it to some lower value, not half of my physical memory.
>>> How can I do it? Can I simply add line in fstab like:
>>>
>>> none /run tmpfs size=128m 0 0         ???
>>>
>>> Jarry
>>
>>
>> Holy smoke !  Mine is doing the same thing.
>> tmpfs                   7.9G  260K  7.9G   1% /run
>>
>> But I also have this:
>> tmpfs                   7.9G     0  7.9G   0% /var/tmp/portage
>>
>> So, between those two, I could run out of ram since I have 16Gbs.
>>
>> There is now TWO people that needs a answer to this question.  Why does
>> it need that much anyway?  It looks to me like a few hundred Mbs, like
>> Jarry posted, would be plenty.  Jeepers creepers.  lol
>>
>> Dale
>
>
> I suppose default size for tmpfs is half of physical memory,
> if it is not configured somewhere else.
>
> BTW, is there any way to turn this great feature off?
> What is it good for? I do not see any advantage in having
> /run on tmpfs...

If /var/run is described in /etc/fstab, then you can use mount options
to control the maximum size of the tmpfs.

http://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt

-- 
:wq

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Neil Bothwick]

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

On Sat, 26 May 2012 22:08:48 +0200, Jarry wrote:

> I suppose default size for tmpfs is half of physical memory,
> if it is not configured somewhere else.

It is, but that is the default maximum size, a tmpfs filesystem uses
only as much memory as its contents require.
 
> BTW, is there any way to turn this great feature off?
> What is it good for? I do not see any advantage in having
> /run on tmpfs...

It makes sure that /run is available and writeable early in the boot
process, whereas /var/run may not be and / may be mounted ro.


-- 
Neil Bothwick

Of all the people I've met you're certainly one of them

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Michael Mol]

On Sat, May 26, 2012 at 8:28 PM, Dale <rdalek1967@gmail.com> wrote:

[snip]

> I had no idea it was doing this either until your post.  I got the same
> questions as you do.  Why is it there?

tmpfs is frequently used in places where data doesn't need to persist
across reboots. /var/run meets this description, because it usually
contains files that have PID numbers for running daemons. (i.e. an
init script spawns acpid, saves the PID of that instance into a file
under /var/run, and consults that file on future runs to see if the
daemon it's responsible for is running).

It also appears to be where udev keeps its current understanding of
the running host machine.

>  Why so much is allocated to it?

It's not, really. That's a *maximum* theoretical size, which is only
reached if files are placed there.

From here, I'm currently booted into the Gentoo LiveDVD (2012.1). /run
is mounted tmpfs, and contains 668K of files.

>  Where can we change the settings for this questionable "feature"?

It's not so bad. Really.

>
> I'm hoping someone will come along and answer both our questions.  I'm
> really hoping for a place we can change the settings.  I don't mind it
> being there so much if it is useful.   I would like to know its purpose
> tho.

A pretty straightforward read:

http://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt

Incidentally, with tmpfs, infrequently-used files may be swapped to
disk, at which point tmpfs starts behaving like a non-persistent
disk-based filesystem. i.e., it becomes useful for things you'd like
cleaned up on reboot.

-- 
:wq

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Alex Schuster]

Dale writes:

> Jarry wrote:
>> On 26-May-12 22:01, Dale wrote:
>>> Jarry wrote:
>>>>
>>>> after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted
>>>> as tmpfs. But I can not find any mount-option for controlling
>>>> how much memory is (or could be) used for it.
>>>>
>>>> Filesystem     1K-blocks    Used Available Use% Mounted on
>>>> tmpfs            8223848     224   8223624   1% /run
>>>>
>>>> I know it does not use 8GB right now, yet I'd like to reduce
>>>> it to some lower value, not half of my physical memory.
>>>> How can I do it? Can I simply add line in fstab like:
>>>>
>>>> none /run tmpfs size=128m 0 0         ???

Just try it :) I don't know if this would work, probably yes. But you
can change it later with mount -o remount,size=128m /run

>>> Holy smoke !  Mine is doing the same thing.
>>> tmpfs                   7.9G  260K  7.9G   1% /run
>>>
>>> But I also have this:
>>> tmpfs                   7.9G     0  7.9G   0% /var/tmp/portage

Now have a look at /dev/shm...

>>> So, between those two, I could run out of ram since I have 16Gbs.

But only if you copy stuff to /run yourself, otherwise this will never
happen.

>>> There is now TWO people that needs a answer to this question.  Why does
>>> it need that much anyway?  It looks to me like a few hundred Mbs, like
>>> Jarry posted, would be plenty.  Jeepers creepers.  lol

It doesn't need it, it's just the maximum sitze, which it will never reach.


>> I suppose default size for tmpfs is half of physical memory,
>> if it is not configured somewhere else.
>>
>> BTW, is there any way to turn this great feature off?
>> What is it good for? I do not see any advantage in having
>> /run on tmpfs...

In case of power failure or lockup, the contents are lost, and will not
cause confusion on the next reboot when /run is still populated by
stuff. Just an idea, I do not know if it would really matter.
But it does no harm, so why not juest keep it like it is.


> I had no idea it was doing this either until your post.  I got the same
> questions as you do.  Why is it there?  Why so much is allocated to it?
>  Where can we change the settings for this questionable "feature"?
> 
> I'm hoping someone will come along and answer both our questions.  I'm
> really hoping for a place we can change the settings.  I don't mind it
> being there so much if it is useful.   I would like to know its purpose
> tho.

I don't know the details, but I'd think it does not matter. There will
nothing be put into /run that uses a lot of memory, so it will never
actually use its default size of half of your RAM.

	Wonko

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Michael Hampicke]

Am 26.05.2012 22:28, schrieb Dale:
> Jarry wrote:
>> On 26-May-12 22:01, Dale wrote:
>>> Jarry wrote:
>>>>
>>>> after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted
>>>> as tmpfs. But I can not find any mount-option for controlling
>>>> how much memory is (or could be) used for it.
>>>>
>>>> Filesystem     1K-blocks    Used Available Use% Mounted on
>>>> tmpfs            8223848     224   8223624   1% /run
>>>>
>>>> I know it does not use 8GB right now, yet I'd like to reduce
>>>> it to some lower value, not half of my physical memory.
>>>> How can I do it? Can I simply add line in fstab like:
>>>>
>>>> none /run tmpfs size=128m 0 0         ???
>>>>
>>>> Jarry
>>>
>>> Holy smoke !  Mine is doing the same thing.
>>> tmpfs                   7.9G  260K  7.9G   1% /run
>>>
>>> But I also have this:
>>> tmpfs                   7.9G     0  7.9G   0% /var/tmp/portage
>>>
>>> So, between those two, I could run out of ram since I have 16Gbs.
>>>
>>> There is now TWO people that needs a answer to this question.  Why does
>>> it need that much anyway?  It looks to me like a few hundred Mbs, like
>>> Jarry posted, would be plenty.  Jeepers creepers.  lol
>>>
>>> Dale
>>
>> I suppose default size for tmpfs is half of physical memory,
>> if it is not configured somewhere else.
>>
>> BTW, is there any way to turn this great feature off?
>> What is it good for? I do not see any advantage in having
>> /run on tmpfs...
>>
>> Jarry
> 
> 
> I had no idea it was doing this either until your post.  I got the same
> questions as you do.  Why is it there?  Why so much is allocated to it?
>  Where can we change the settings for this questionable "feature"?
> 
> I'm hoping someone will come along and answer both our questions.  I'm
> really hoping for a place we can change the settings.  I don't mind it
> being there so much if it is useful.   I would like to know its purpose
> tho.

As Michael Mol already said, tmpfs for the run dir is not a bad thing,
it, it does not eat all your ram :)
I however have a different question: Why do we need a new /run when we
already have /var/run. There's no mention of /run in the FHS either.
I only see udev stuff under /run - So it's another crazy udev thing? :)

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Michael Mol]

On Sat, May 26, 2012 at 9:02 PM, Michael Hampicke <gentoo-user@hadt.biz> wrote:

[snip]

> As Michael Mol already said, tmpfs for the run dir is not a bad thing,
> it, it does not eat all your ram :)
> I however have a different question: Why do we need a new /run when we
> already have /var/run. There's no mention of /run in the FHS either.
> I only see udev stuff under /run - So it's another crazy udev thing? :)

Neil had the best response to that, IMO:


"It makes sure that /run is available and writeable early in the boot
process, whereas /var/run may not be and / may be mounted ro."

-- 
:wq

[gentoo-user] Re: How can I control size of /run (tmpfs)?

[Nikos Chantziaras]

On 26/05/12 22:46, Jarry wrote:
> Hi,
>
> after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted
> as tmpfs. But I can not find any mount-option for controlling
> how much memory is (or could be) used for it.
>
> Filesystem 1K-blocks Used Available Use% Mounted on
> tmpfs 8223848 224 8223624 1% /run
>
> I know it does not use 8GB right now, yet I'd like to reduce
> it to some lower value, not half of my physical memory.
> How can I do it? Can I simply add line in fstab like:
>
> none /run tmpfs size=128m 0 0 ???

Id doesn't make any sense to change the default:

  a) tmpfs doesn't use RAM if there are no files in it

  b) If you make /run smaller and then it fills up, you're fucked

So with a basic application of logic, there is no reason to change it.

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Dale]

Neil Bothwick wrote:
> On Sat, 26 May 2012 22:08:48 +0200, Jarry wrote:
> 
>> I suppose default size for tmpfs is half of physical memory,
>> if it is not configured somewhere else.
> 
> It is, but that is the default maximum size, a tmpfs filesystem uses
> only as much memory as its contents require.
>  
>> BTW, is there any way to turn this great feature off?
>> What is it good for? I do not see any advantage in having
>> /run on tmpfs...
> 
> It makes sure that /run is available and writeable early in the boot
> process, whereas /var/run may not be and / may be mounted ro.
> 
> 


Mine wouldn't be since I have /var on a separate partition.  I guess the
devs are getting ready for the ultimate screwup udev and friends is
putting in place.  Oh well.  This is life.

I just hope it never goes bonkers and tries to use half my ram.  lol  If
it did that while compiling LOo, that could be interesting.  :/

Thanks for the info from all the replies. .

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Neil Bothwick]

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

On Sat, 26 May 2012 17:17:54 -0500, Dale wrote:

> > It makes sure that /run is available and writeable early in the boot
> > process, whereas /var/run may not be and / may be mounted ro.

> Mine wouldn't be since I have /var on a separate partition.  I guess the
> devs are getting ready for the ultimate screwup udev and friends is
> putting in place.

No, it's avoiding a screwup. If you have /var on a separate partition, as
I do, and something early in the boot process writes to /var/run
(or /var/lock) whatever is written disappears when the var filesystem is
mounted on /var. Using a tmpfs in / prevent this.

The alternative is to require /var is on the same filesystem as / or
mounted from an initramfs. ISTR you were rather against such a move.

This move makes perfect sense, volatile but essential data is kept in ram
rather than on a filesystem that may not always be available. If you are
really bothered about the maximum size, remount it, although an option to
specify this in rc.conf may possibly be useful in some situations.


-- 
Neil Bothwick

(A)bort, (R)etry, (P)retend this never happened...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Michael Mol]

On Sat, May 26, 2012 at 10:17 PM, Dale <rdalek1967@gmail.com> wrote:
> Neil Bothwick wrote:
>> On Sat, 26 May 2012 22:08:48 +0200, Jarry wrote:
>>
>>> I suppose default size for tmpfs is half of physical memory,
>>> if it is not configured somewhere else.
>>
>> It is, but that is the default maximum size, a tmpfs filesystem uses
>> only as much memory as its contents require.
>>
>>> BTW, is there any way to turn this great feature off?
>>> What is it good for? I do not see any advantage in having
>>> /run on tmpfs...
>>
>> It makes sure that /run is available and writeable early in the boot
>> process, whereas /var/run may not be and / may be mounted ro.
>>
>>
>
>
> Mine wouldn't be since I have /var on a separate partition.  I guess the
> devs are getting ready for the ultimate screwup udev and friends is
> putting in place.  Oh well.  This is life.

TBH, there are other occasions for / to be read-only. LiveCDs, for
example, where your entire filesystem is (at least initially) R/O. A
read-only network filesystem (or disk image) mount in thin clients.
That kind of thing.

>
> I just hope it never goes bonkers and tries to use half my ram.  lol  If
> it did that while compiling LOo, that could be interesting.  :/

tmpfs specifically allows pages in it to be swapped out to disk, so if
you have a large amount of swap, you shouldn't have a problem.

FWIW, I try to avoid swap on my servers, but I try to keep my desktop
and dual-role boxes with at least 1xRAM in SWAP, just in case I
someday decide to experiment with suspend-to-disk. I rarely (if ever)
touch it, but it's there if I need it.

-- 
:wq

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Dale]

Neil Bothwick wrote:
> On Sat, 26 May 2012 17:17:54 -0500, Dale wrote:
> 
>>> It makes sure that /run is available and writeable early in the boot
>>> process, whereas /var/run may not be and / may be mounted ro.
> 
>> Mine wouldn't be since I have /var on a separate partition.  I guess the
>> devs are getting ready for the ultimate screwup udev and friends is
>> putting in place.
> 
> No, it's avoiding a screwup. If you have /var on a separate partition, as
> I do, and something early in the boot process writes to /var/run
> (or /var/lock) whatever is written disappears when the var filesystem is
> mounted on /var. Using a tmpfs in / prevent this.
> 
> The alternative is to require /var is on the same filesystem as / or
> mounted from an initramfs. ISTR you were rather against such a move.
> 
> This move makes perfect sense, volatile but essential data is kept in ram
> rather than on a filesystem that may not always be available. If you are
> really bothered about the maximum size, remount it, although an option to
> specify this in rc.conf may possibly be useful in some situations.
> 
> 


I was talking about the /usr and/or /var being needed and the init
thingy.  I was not talking about /run using tmpfs or even being used.
In other words, the /usr and/or /var being needed very early in the boot
process is the screwup, not /run being used and on tmpfs.  It appears
that /run is sort of a temp thing while booting and just sort of sticks
around after getting booted, since it is there anyway.  Why not use it?

Sort of hard to explain my thinking sometimes.  lol  I have those days,
quite often I'm afraid.  :/

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Alan McKinnon]

On Sat, 26 May 2012 18:17:38 -0500
Dale <rdalek1967@gmail.com> wrote:

> It
> appears that /run is sort of a temp thing while booting and just sort
> of sticks around after getting booted, since it is there anyway.  Why
> not use it?

No, that is incorrect.

/run is a deliberate design decision (and a damn good one that should
always have been there IMHO) and it sticks around because it is
supposed to. It's not an after-effect that just happens to be useful,
it's the entire objective.

Think of it in the same way you think of /dev, /proc and /sys:

There are there, there are guaranteed to be there with certain
behaviours, and you can't change that (neither should you want to).

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Alan McKinnon]

On Sat, 26 May 2012 23:02:13 +0200
Michael Hampicke <gentoo-user@hadt.biz> wrote:

> 
> 
> Am 26.05.2012 22:28, schrieb Dale:
> > Jarry wrote:
> >> On 26-May-12 22:01, Dale wrote:
> >>> Jarry wrote:
> >>>>
> >>>> after updating baselayout from 2.0.3 to 2.1-r1 /run is mounted
> >>>> as tmpfs. But I can not find any mount-option for controlling
> >>>> how much memory is (or could be) used for it.
> >>>>
> >>>> Filesystem     1K-blocks    Used Available Use% Mounted on
> >>>> tmpfs            8223848     224   8223624   1% /run
> >>>>
> >>>> I know it does not use 8GB right now, yet I'd like to reduce
> >>>> it to some lower value, not half of my physical memory.
> >>>> How can I do it? Can I simply add line in fstab like:
> >>>>
> >>>> none /run tmpfs size=128m 0 0         ???
> >>>>
> >>>> Jarry
> >>>
> >>> Holy smoke !  Mine is doing the same thing.
> >>> tmpfs                   7.9G  260K  7.9G   1% /run
> >>>
> >>> But I also have this:
> >>> tmpfs                   7.9G     0  7.9G   0% /var/tmp/portage
> >>>
> >>> So, between those two, I could run out of ram since I have 16Gbs.
> >>>
> >>> There is now TWO people that needs a answer to this question.
> >>> Why does it need that much anyway?  It looks to me like a few
> >>> hundred Mbs, like Jarry posted, would be plenty.  Jeepers
> >>> creepers.  lol
> >>>
> >>> Dale
> >>
> >> I suppose default size for tmpfs is half of physical memory,
> >> if it is not configured somewhere else.
> >>
> >> BTW, is there any way to turn this great feature off?
> >> What is it good for? I do not see any advantage in having
> >> /run on tmpfs...
> >>
> >> Jarry
> > 
> > 
> > I had no idea it was doing this either until your post.  I got the
> > same questions as you do.  Why is it there?  Why so much is
> > allocated to it? Where can we change the settings for this
> > questionable "feature"?
> > 
> > I'm hoping someone will come along and answer both our questions.
> > I'm really hoping for a place we can change the settings.  I don't
> > mind it being there so much if it is useful.   I would like to know
> > its purpose tho.
> 
> As Michael Mol already said, tmpfs for the run dir is not a bad thing,
> it, it does not eat all your ram :)
> I however have a different question: Why do we need a new /run when we
> already have /var/run. There's no mention of /run in the FHS either.
> I only see udev stuff under /run - So it's another crazy udev
> thing? :)
> 

/var can fail to mount, then you have no /var/run.

FHS isn't much as standards go. It's a bunch of good ideas (some less
so than others but it has always been just good (unenforceable) ideas.

As to why only udev stuff is in /run, that's because udev is the only
thing you have that's using it (currently). That might change, but it's
up to individual package authors.



-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Dale]

Alan McKinnon wrote:
> On Sat, 26 May 2012 18:17:38 -0500
> Dale <rdalek1967@gmail.com> wrote:
> 
>> It
>> appears that /run is sort of a temp thing while booting and just sort
>> of sticks around after getting booted, since it is there anyway.  Why
>> not use it?
> 
> No, that is incorrect.
> 
> /run is a deliberate design decision (and a damn good one that should
> always have been there IMHO) and it sticks around because it is
> supposed to. It's not an after-effect that just happens to be useful,
> it's the entire objective.
> 
> Think of it in the same way you think of /dev, /proc and /sys:
> 
> There are there, there are guaranteed to be there with certain
> behaviours, and you can't change that (neither should you want to).
> 


What I was saying tho, since it appears to be needed now, since /var may
not be mounted yet, it was created and is used during booting up.  Since
it is there, why not use it, even AFTER the system is booted.  After
all,  the files are already there since they were put there during boot
up.  No need moving them and all that when they are already created and
available.

Plus, as someone said, I think it was you in another reply, what if /var
fails to mount at all?  At that point, it still works since /run is
there already.  Since /run is on tmpfs, if it fails to mount for some
reason, you got issues already.  ;-)

I don't mind it being there, I just hope udev, or whatever else may use
it later on, doesn't get memory hungry.   Actually, maybe some other
small directories could be placed there as well.  The lock files would
be a good one to start with.  Just thinking.  May want to duck tho.  lol

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Pandu Poluan]

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

On May 27, 2012 7:19 AM, "Dale" <rdalek1967@gmail.com> wrote:
>
> Alan McKinnon wrote:
> > On Sat, 26 May 2012 18:17:38 -0500
> > Dale <rdalek1967@gmail.com> wrote:
> >
> >> It
> >> appears that /run is sort of a temp thing while booting and just sort
> >> of sticks around after getting booted, since it is there anyway.  Why
> >> not use it?
> >
> > No, that is incorrect.
> >
> > /run is a deliberate design decision (and a damn good one that should
> > always have been there IMHO) and it sticks around because it is
> > supposed to. It's not an after-effect that just happens to be useful,
> > it's the entire objective.
> >
> > Think of it in the same way you think of /dev, /proc and /sys:
> >
> > There are there, there are guaranteed to be there with certain
> > behaviours, and you can't change that (neither should you want to).
> >
>
>
> What I was saying tho, since it appears to be needed now, since /var may
> not be mounted yet, it was created and is used during booting up.  Since
> it is there, why not use it, even AFTER the system is booted.  After
> all,  the files are already there since they were put there during boot
> up.  No need moving them and all that when they are already created and
> available.
>
> Plus, as someone said, I think it was you in another reply, what if /var
> fails to mount at all?  At that point, it still works since /run is
> there already.  Since /run is on tmpfs, if it fails to mount for some
> reason, you got issues already.  ;-)
>
> I don't mind it being there, I just hope udev, or whatever else may use
> it later on, doesn't get memory hungry.   Actually, maybe some other
> small directories could be placed there as well.  The lock files would
> be a good one to start with.  Just thinking.  May want to duck tho.  lol
>

You mean /var/lock ? Hasn't it transmogrified to /run/lock now?

Rgds,

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

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Dale]

Pandu Poluan wrote:
> 
> On May 27, 2012 7:19 AM, "Dale" <rdalek1967@gmail.com

>>
>> What I was saying tho, since it appears to be needed now, since /var may
>> not be mounted yet, it was created and is used during booting up.  Since
>> it is there, why not use it, even AFTER the system is booted.  After
>> all,  the files are already there since they were put there during boot
>> up.  No need moving them and all that when they are already created and
>> available.
>>
>> Plus, as someone said, I think it was you in another reply, what if /var
>> fails to mount at all?  At that point, it still works since /run is
>> there already.  Since /run is on tmpfs, if it fails to mount for some
>> reason, you got issues already.  ;-)
>>
>> I don't mind it being there, I just hope udev, or whatever else may use
>> it later on, doesn't get memory hungry.   Actually, maybe some other
>> small directories could be placed there as well.  The lock files would
>> be a good one to start with.  Just thinking.  May want to duck tho.  lol
>>
> 
> You mean /var/lock ? Hasn't it transmogrified to /run/lock now?
> 
> Rgds,
> 

Well, the /run/lock directory is there but there is nothing in it on
mine.  It does look to me like they would move the files from /var/lock,
or any other lock files, there tho.  They appear to be small here since
it takes up so little space.

root@fireball / # du -shc /var/lock/
32K     /var/lock/
32K     total
root@fireball / #

That would total up to be less than 300K for what is there and /var/lock
on my machine.

I dunno.  Just makes sense to me.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Joshua Murphy]

On Sun, May 27, 2012 at 3:06 AM, Dale <rdalek1967@gmail.com> wrote:
> Pandu Poluan wrote:
>>
>> On May 27, 2012 7:19 AM, "Dale" <rdalek1967@gmail.com
>
>>>
>>> What I was saying tho, since it appears to be needed now, since /var may
>>> not be mounted yet, it was created and is used during booting up.  Since
>>> it is there, why not use it, even AFTER the system is booted.  After
>>> all,  the files are already there since they were put there during boot
>>> up.  No need moving them and all that when they are already created and
>>> available.
>>>
>>> Plus, as someone said, I think it was you in another reply, what if /var
>>> fails to mount at all?  At that point, it still works since /run is
>>> there already.  Since /run is on tmpfs, if it fails to mount for some
>>> reason, you got issues already.  ;-)
>>>
>>> I don't mind it being there, I just hope udev, or whatever else may use
>>> it later on, doesn't get memory hungry.   Actually, maybe some other
>>> small directories could be placed there as well.  The lock files would
>>> be a good one to start with.  Just thinking.  May want to duck tho.  lol
>>>
>>
>> You mean /var/lock ? Hasn't it transmogrified to /run/lock now?
>>
>> Rgds,
>>
>
> Well, the /run/lock directory is there but there is nothing in it on
> mine.  It does look to me like they would move the files from /var/lock,
> or any other lock files, there tho.  They appear to be small here since
> it takes up so little space.
>
> root@fireball / # du -shc /var/lock/
> 32K     /var/lock/
> 32K     total
> root@fireball / #
>
> That would total up to be less than 300K for what is there and /var/lock
> on my machine.
>
> I dunno.  Just makes sense to me.
>
> Dale
>
> :-)  :-)
>
> --
> I am only responsible for what I said ... Not for what you understood or
> how you interpreted my words!
>
> Miss the compile output?  Hint:
> EMERGE_DEFAULT_OPTS="--quiet-build=n"

Well, given that it's there, it cleans up after itself, and it avoids
issues in the instance where /var isn't available early on, is there
much reason _not_ to link /var/run and /var/lock over to their
respective equivalents on /run? And both with and without /var mounted
(so they exist and are writable even if /var doesn't come up)? If I
recall its purpose properly, /var exists to hold data that _needs_ to
be writable in an actively running system, logs, lock files, caches,
etc.. but as tmpfs didn't exist back when it was thought up, no
separation was explicitly defined between persistent and
non-persistent data. With /run around now, there's an explicitly
defined lack of persistence that would suit /var/run and /var/lock
rather well, since stale service pids, lock files, and the like can
wreak havoc on an unplanned restart (which tends to be bad enough with
the prospect of, say, a failed UPS as it is). Also, any
inconsistencies in the above rambling curiosity (as well as the
rambling itself, I should note) are the result of having been awake
far too early for a Saturday, and still being awake for the start of
Sunday, so apologies may be required on my part.

-- 
Poison [BLX]
Joshua M. Murphy

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Dale]

Joshua Murphy wrote:

> Well, given that it's there, it cleans up after itself, and it avoids
> issues in the instance where /var isn't available early on, is there
> much reason _not_ to link /var/run and /var/lock over to their
> respective equivalents on /run? And both with and without /var mounted
> (so they exist and are writable even if /var doesn't come up)? If I
> recall its purpose properly, /var exists to hold data that _needs_ to
> be writable in an actively running system, logs, lock files, caches,
> etc.. but as tmpfs didn't exist back when it was thought up, no
> separation was explicitly defined between persistent and
> non-persistent data. With /run around now, there's an explicitly
> defined lack of persistence that would suit /var/run and /var/lock
> rather well, since stale service pids, lock files, and the like can
> wreak havoc on an unplanned restart (which tends to be bad enough with
> the prospect of, say, a failed UPS as it is). Also, any
> inconsistencies in the above rambling curiosity (as well as the
> rambling itself, I should note) are the result of having been awake
> far too early for a Saturday, and still being awake for the start of
> Sunday, so apologies may be required on my part.
> 


Well, I don't see why not.  As you say, lack of a proper clean up after
a bad shutdown can cause problems.  Anything in /run would disappear
after a shutdown, clean or not, since it is in tmpfs.   It doesn't seem
to use much ram either.  I really don't know of a reason why it couldn't
be set that way.  I'm not the sharpest tool in the shed tho.  lol

As for one of us setting it to do that manually, I guess one could do
that.  If I recall correctly, /var/lock is *supposed* to be cleaned up
when booting but that was a good long while ago.  This may be something
the devs are already getting ready for.  I get the feeling that they are
taking what I call baby steps.  I noticed a upgrade to baselayout and I
think OpenRC as well not long ago.  I'm not sure what decided to put
stuff in /run.  I would think it would be one of those but it could be
some other package.  I guess udev could be one that could have made it
as well.  It does have a directory in there that has stuff in it.  The
rest are empty.

I'd wait for a serious guru to reply before changing anything tho, just
to be safe.  ;-)

You think being up late at night is bad.  You should see me when my meds
are making me goofy.  lol

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Joshua Murphy]

On Sun, May 27, 2012 at 4:51 AM, Dale <rdalek1967@gmail.com> wrote:
> Joshua Murphy wrote:
<snip>
>
> Well, I don't see why not.  As you say, lack of a proper clean up after
> a bad shutdown can cause problems.  Anything in /run would disappear
> after a shutdown, clean or not, since it is in tmpfs.   It doesn't seem
> to use much ram either.  I really don't know of a reason why it couldn't
> be set that way.  I'm not the sharpest tool in the shed tho.  lol
>
> As for one of us setting it to do that manually, I guess one could do
> that.  If I recall correctly, /var/lock is *supposed* to be cleaned up
> when booting but that was a good long while ago.  This may be something
> the devs are already getting ready for.  I get the feeling that they are
> taking what I call baby steps.  I noticed a upgrade to baselayout and I
> think OpenRC as well not long ago.  I'm not sure what decided to put
> stuff in /run.  I would think it would be one of those but it could be
> some other package.  I guess udev could be one that could have made it
> as well.  It does have a directory in there that has stuff in it.  The
> rest are empty.
>
> I'd wait for a serious guru to reply before changing anything tho, just
> to be safe.  ;-)
>
> You think being up late at night is bad.  You should see me when my meds
> are making me goofy.  lol
>
> Dale
>
> :-)  :-)


I would try it right now, but

a) the only proper 'desktop' I have running is a windows box, the rest
of my systems, netbook, laptops, and servers, are stripped down to the
bare essentials and are likely to continue skipping along smoothly for
a long while regardless of what I do to them, hardly a useful test for
something that could potentially cause catastrophic breakage for more
'normal' systems, and

b) if it *did* break, I would dread it as I went about trying to
remember my exact steps to get there after I wake up tomorrow,
especially with the fact that I'm aiming to head to the office when I
wake, rather than toy around with fixing things here at home.

Maybe tomorrow evening on a couple systems, if the idea itself doesn't
bring about any "don't do this, you'll break <x>" responses between
now and then (and, depending on the severity of the potential
breakage, may still have to poke it with a stick).

-- 
Poison [BLX]
Joshua M. Murphy

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Dale]

Joshua Murphy wrote:
> On Sun, May 27, 2012 at 4:51 AM, Dale <rdalek1967@gmail.com> wrote:
>> Joshua Murphy wrote:
> <snip>
>>
>> Well, I don't see why not.  As you say, lack of a proper clean up after
>> a bad shutdown can cause problems.  Anything in /run would disappear
>> after a shutdown, clean or not, since it is in tmpfs.   It doesn't seem
>> to use much ram either.  I really don't know of a reason why it couldn't
>> be set that way.  I'm not the sharpest tool in the shed tho.  lol
>>
>> As for one of us setting it to do that manually, I guess one could do
>> that.  If I recall correctly, /var/lock is *supposed* to be cleaned up
>> when booting but that was a good long while ago.  This may be something
>> the devs are already getting ready for.  I get the feeling that they are
>> taking what I call baby steps.  I noticed a upgrade to baselayout and I
>> think OpenRC as well not long ago.  I'm not sure what decided to put
>> stuff in /run.  I would think it would be one of those but it could be
>> some other package.  I guess udev could be one that could have made it
>> as well.  It does have a directory in there that has stuff in it.  The
>> rest are empty.
>>
>> I'd wait for a serious guru to reply before changing anything tho, just
>> to be safe.  ;-)
>>
>> You think being up late at night is bad.  You should see me when my meds
>> are making me goofy.  lol
>>
>> Dale
>>
>> :-)  :-)
> 
> 
> I would try it right now, but
> 
> a) the only proper 'desktop' I have running is a windows box, the rest
> of my systems, netbook, laptops, and servers, are stripped down to the
> bare essentials and are likely to continue skipping along smoothly for
> a long while regardless of what I do to them, hardly a useful test for
> something that could potentially cause catastrophic breakage for more
> 'normal' systems, and
> 
> b) if it *did* break, I would dread it as I went about trying to
> remember my exact steps to get there after I wake up tomorrow,
> especially with the fact that I'm aiming to head to the office when I
> wake, rather than toy around with fixing things here at home.
> 
> Maybe tomorrow evening on a couple systems, if the idea itself doesn't
> bring about any "don't do this, you'll break <x>" responses between
> now and then (and, depending on the severity of the potential
> breakage, may still have to poke it with a stick).
> 


Be careful, sometimes when you poke things with a stick, it bites.  ROFL

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Canek Peláez Valdés]

On Sat, May 26, 2012 at 11:29 PM, Joshua Murphy <poisonbl@gmail.com> wrote:
[ snip ]
> Well, given that it's there, it cleans up after itself, and it avoids
> issues in the instance where /var isn't available early on, is there
> much reason _not_ to link /var/run and /var/lock over to their
> respective equivalents on /run?

I use systemd, which was the one introducing both /run and /run/lock:

http://lists.freedesktop.org/archives/systemd-devel/2011-March/001757.html

With systemd, /var/run and /var/lock are bind-mounted to /run and
/run/lock respectively. /run uses in my laptop (regularly suspended,
with an uptime of 25 days) 8.8 megabytes, which I think is basically
nothing for my 4 gigabyte RAM.

After more programs (dracut, plymouth) started using /run and
/run/lock, OpenRC implemented the same functionality; or so I read
somewhere, I haven't used OpenRC in a while. In theory, it should work
the same as with systemd.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Canek Peláez Valdés]

On Sun, May 27, 2012 at 1:20 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Sat, May 26, 2012 at 11:29 PM, Joshua Murphy <poisonbl@gmail.com> wrote:
> [ snip ]
>> Well, given that it's there, it cleans up after itself, and it avoids
>> issues in the instance where /var isn't available early on, is there
>> much reason _not_ to link /var/run and /var/lock over to their
>> respective equivalents on /run?
>
> I use systemd, which was the one introducing both /run and /run/lock:
>
> http://lists.freedesktop.org/archives/systemd-devel/2011-March/001757.html
>
> With systemd, /var/run and /var/lock are bind-mounted to /run and
> /run/lock respectively. /run uses in my laptop (regularly suspended,
> with an uptime of 25 days) 8.8 megabytes, which I think is basically
> nothing for my 4 gigabyte RAM.
>
> After more programs (dracut, plymouth) started using /run and
> /run/lock, OpenRC implemented the same functionality; or so I read
> somewhere, I haven't used OpenRC in a while. In theory, it should work
> the same as with systemd.

I take that back; OpenRC doesn't bind-mount /run in /var/run. I ssh'd
to a server running OpenRC, and /var/run is independent from /run. And
still a regular directory, not a tmpfs.

That's a shame. Given that udev uses /run (stable "old" version,
171-r6), OpenRC should use it too; there is basically no cost, and the
gains are obvious.

With systemd is automatic the bind-mounting of /run into /var/run.
Perhaps a future version of OpenRC will use it?

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Jarry]

I have read through all replies, but I still did not find
answers to my original questions:

Q1: Can I somehow reduce the size of /run? I know it is tmpfs
and I know this is upper limit normally never achieved, but
I want to reduce this upper limit. Is it possible, or is it
hard-coded to half of physical memory?

Q2: Can I turn this "/run in tmpfs" feature off? I do not
see *any* advantage in vasting memory for /run (although
I agree there might be some point in moving "run" from
/var/run to /run). But I see one big problem:

If badly written application starts writing some crap in
/run, it could deadlock my computer quite easily. And before
you ask, no it is not so easy to do with /run on hard-drive
because I have plenty of TB there and monitoring software
running which alerts me as soon as any partition is half
full. Unfortunatelly this does not work for tmpfs because
with given read/write speed of ram-disk it would be full
in a few seconds before I had any chance to act...

Jarry

-- 
_______________________________________________________________
This mailbox accepts e-mails only from selected mailing-lists!
Everything else is considered to be spam and therefore deleted.

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Alan McKinnon]

On Sun, 27 May 2012 09:05:46 +0200
Jarry <mr.jarry@gmail.com> wrote:

> I have read through all replies, but I still did not find
> answers to my original questions:
> 
> Q1: Can I somehow reduce the size of /run? I know it is tmpfs
> and I know this is upper limit normally never achieved, but
> I want to reduce this upper limit. Is it possible, or is it
> hard-coded to half of physical memory?

I think this works IIRC:

List it in /etc/fstab. Max size goes in the options field using the
syntax described in man mount


> Q2: Can I turn this "/run in tmpfs" feature off? I do not
> see *any* advantage in vasting memory for /run (although
> I agree there might be some point in moving "run" from
> /var/run to /run). But I see one big problem:


If if limit the tmpfs to say 100M or so then this is not a problem at
all


> 
> If badly written application starts writing some crap in
> /run, it could deadlock my computer quite easily. And before
> you ask, no it is not so easy to do with /run on hard-drive
> because I have plenty of TB there and monitoring software
> running which alerts me as soon as any partition is half
> full. Unfortunatelly this does not work for tmpfs because
> with given read/write speed of ram-disk it would be full
> in a few seconds before I had any chance to act...
> 
> Jarry
> 



-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Neil Bothwick]

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

On Sun, 27 May 2012 04:29:17 +0000, Joshua Murphy wrote:

> Well, given that it's there, it cleans up after itself, and it avoids
> issues in the instance where /var isn't available early on, is there
> much reason _not_ to link /var/run and /var/lock over to their
> respective equivalents on /run? And both with and without /var mounted
> (so they exist and are writable even if /var doesn't come up)? 

I did that months ago to resolve an issue with a specific package that
hadn't been updated to use /run at the time. I never got round to
removing the links and it has caused no problems.


-- 
Neil Bothwick

Suicidal twin kills sister by mistake!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Neil Bothwick]

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

On Sun, 27 May 2012 09:05:46 +0200, Jarry wrote:

> I have read through all replies, but I still did not find
> answers to my original questions:
> 
> Q1: Can I somehow reduce the size of /run? I know it is tmpfs
> and I know this is upper limit normally never achieved, but
> I want to reduce this upper limit. Is it possible, or is it
> hard-coded to half of physical memory?

That has been answered, either use fstab, which may or not work, or mount
-o remount, which should.
 
> Q2: Can I turn this "/run in tmpfs" feature off? I do not
> see *any* advantage in vasting memory for /run

Given that /var/run would be cached, at least initially, there is no more
memory usage.

> If badly written application starts writing some crap in
> /run, it could deadlock my computer quite easily. And before
> you ask, no it is not so easy to do with /run on hard-drive
> because I have plenty of TB there and monitoring software
> running which alerts me as soon as any partition is half
> full. Unfortunatelly this does not work for tmpfs because
> with given read/write speed of ram-disk it would be full
> in a few seconds before I had any chance to act...

Except that the default size is HALF your RAM, so something else would
need to be using the other half and all your swap (tmpfs will use swap if
physical memory is not available).


-- 
Neil Bothwick

Octal: (n.) a base-8 counting system designed so that one hand may count
upon the fingers of the other. Thumbs are not used, and the index finger
is reserved for the 'carry.'

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[William Kenworthy]

On Sun, 2012-05-27 at 09:59 +0200, Alan McKinnon wrote:
> On Sun, 27 May 2012 09:05:46 +0200
> Jarry <mr.jarry@gmail.com> wrote:
> 
> > I have read through all replies, but I still did not find
> > answers to my original questions:
> > 
> > Q1: Can I somehow reduce the size of /run? I know it is tmpfs
> > and I know this is upper limit normally never achieved, but
> > I want to reduce this upper limit. Is it possible, or is it
> > hard-coded to half of physical memory?
> 
> I think this works IIRC:
> 
> List it in /etc/fstab. Max size goes in the options field using the
> syntax described in man mount
> 
> 
> > Q2: Can I turn this "/run in tmpfs" feature off? I do not
> > see *any* advantage in vasting memory for /run (although
> > I agree there might be some point in moving "run" from
> > /var/run to /run). But I see one big problem:
> 
> 
> If if limit the tmpfs to say 100M or so then this is not a problem at
> all
> 
> 
> > 
> > If badly written application starts writing some crap in
> > /run, it could deadlock my computer quite easily. And before
> > you ask, no it is not so easy to do with /run on hard-drive
> > because I have plenty of TB there and monitoring software
> > running which alerts me as soon as any partition is half
> > full. Unfortunatelly this does not work for tmpfs because
> > with given read/write speed of ram-disk it would be full
> > in a few seconds before I had any chance to act...
> > 
> > Jarry
> > 
> 
> 
> 

all on one line:

tmpfs                   /tmp            tmpfs
size=2500M,mode=1777,noatime,auto               0 0


4G ram (diskless, atom board) works well
3G on an otherwise similar system goes bang when compiling glibc or gcc
as portage and portage tmp in /tmp and ram needed for compiling meet in
the middle :)

Helped by swap on an NDB and mapping some space over NFS when really
needed.

BillK

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Walter Dnes]

On Sat, May 26, 2012 at 05:17:54PM -0500, Dale wrote

> I guess the devs are getting ready for the ultimate screwup udev
> and friends is putting in place.  Oh well.  This is life.

  I guess that explains why I have /var/run but no /run on my mdev-based
system. <G>

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Pandu Poluan]

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

On May 28, 2012 9:11 AM, "Walter Dnes" <waltdnes@waltdnes.org> wrote:
>
> On Sat, May 26, 2012 at 05:17:54PM -0500, Dale wrote
>
> > I guess the devs are getting ready for the ultimate screwup udev
> > and friends is putting in place.  Oh well.  This is life.
>
>  I guess that explains why I have /var/run but no /run on my mdev-based
> system. <G>
>

LOL :-D

That makes two of us, Walt :-)

But my newer servers has /run (and its children) from the get go, because I
think it kind of makes sense. Even though they're udev-free.

Rgds,

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

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[pk]

On 2012-05-28 05:44, Pandu Poluan wrote:

> But my newer servers has /run (and its children) from the get go, because I
> think it kind of makes sense. Even though they're udev-free.

Hm... what is using /run instead of /var/run? I thought it was (newish)
udev itself and things like systemd that uses /run instead of
/var/run... just curious.

Best regards

Peter K

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Jarry]

On 27-May-12 10:24, Neil Bothwick wrote:

>> Q1: Can I somehow reduce the size of /run?
>
> That has been answered, either use fstab, which may or not work, or mount
> -o remount, which should.

Thanks. It works after I added following line in /etc/fstab:
tmpfs   /run   tmpfs   size=128m,mode=1777   0 0

But I'm still missing answer for my second question:

>> Q2: Can I turn this "/run in tmpfs" feature off?

Jarry

-- 
_______________________________________________________________
This mailbox accepts e-mails only from selected mailing-lists!
Everything else is considered to be spam and therefore deleted.

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Michael Mol]

On Mon, May 28, 2012 at 6:31 PM, Jarry <mr.jarry@gmail.com> wrote:
> But I'm still missing answer for my second question:
>>> Q2: Can I turn this "/run in tmpfs" feature off?

Up front: I don't know. Not my area of expertise, but I also don't
think you've given enough information about your system to really
answer.

1) Are you using openrc or systemd? (which version?)
2) Are you using an initramfs? (Generated by what version of what?)
3) Are there any circumstances where your root filesystem is read-only?

But why would you want to? As has been pointed out at least a few
times, and is described in the link I gave earlier, anything in there
will be automatically moved to your swap partition if doing so
benefits your system.

The only circumstances I can think of where this wouldn't happen is if
you don't have swap (understandable in that circumstance), or if you
have swappiness set to 0.

-- 
:wq

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Jarry]

On 28-May-12 20:58, Michael Mol wrote:

>>>> Q2: Can I turn this "/run in tmpfs" feature off?
>
> Up front: I don't know. Not my area of expertise, but I also don't
> think you've given enough information about your system to really
> answer.
>
> 1) Are you using openrc or systemd? (which version?)

openrc 0.9.8.4

> 2) Are you using an initramfs? (Generated by what version of what?)

no, but I might be forced to use it later when udev >=181 becomes
stable.

> 3) Are there any circumstances where your root filesystem is read-only?

The only I know is shutdown, when / is remounted read-only.

> But why would you want to?

I do not see any advantage in having /run on tmpfs.

> will be automatically moved to your swap partition if doing so
> benefits your system.

I'm not sure it is true. I have read somewhere that tmfps is
never moved to swap. Anyway, I prefer not using swap at all.
And I have better use for physical memory than holding some
more-or-less statical data...

<OT>
I always liked Gentoo because it gives me complete freedom
and control over my system. *I* could decide what I want to
use or not. And I'd be very dissapointed if Gentoo one day goes
to "YouCanNotTurnThisOffBecauseWeKnowWhatIsTheBestForYou" way...
</OT>

Jarry
-- 
_______________________________________________________________
This mailbox accepts e-mails only from selected mailing-lists!
Everything else is considered to be spam and therefore deleted.

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Alan McKinnon]

On Mon, 28 May 2012 21:24:59 +0200
Jarry <mr.jarry@gmail.com> wrote:

> I always liked Gentoo because it gives me complete freedom
> and control over my system. *I* could decide what I want to
> use or not. And I'd be very dissapointed if Gentoo one day goes
> to "YouCanNotTurnThisOffBecauseWeKnowWhatIsTheBestForYou" way...

Time to put that myth to bed.

If such a day cometh, it will not be because Gentoo decided to do so.
It will be because the current software available offers little choice;
and simply does it that way and only that way.

Gentoo devs have always stuck close to upstream as mucg as possible -
this is not RedHat with large amounts of paid dev talent to mod, tweak
and patch software to do what RH wants it to do.

So lets please stop blaming Gentoo for the route taken by udev and init
system programmers, OK?

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Michael Mol]

On Mon, May 28, 2012 at 3:24 PM, Jarry <mr.jarry@gmail.com> wrote:
> On 28-May-12 20:58, Michael Mol wrote:
>
>>>>> Q2: Can I turn this "/run in tmpfs" feature off?
>>
>>
>> Up front: I don't know. Not my area of expertise, but I also don't
>> think you've given enough information about your system to really
>> answer.
>>
>> 1) Are you using openrc or systemd? (which version?)
>
>
> openrc 0.9.8.4

I'll let someone more familiary with openrc figure out if/how you'd
reconfigure it wrt /run.

>
>
>> 2) Are you using an initramfs? (Generated by what version of what?)
>
>
> no, but I might be forced to use it later when udev >=181 becomes
> stable.

Is your /usr on a separate partition?

[snip]

>> But why would you want to?
>
>
> I do not see any advantage in having /run on tmpfs.
>
>> will be automatically moved to your swap partition if doing so
>> benefits your system.
>
>
> I'm not sure it is true. I have read somewhere that tmfps is
> never moved to swap.

Then you didn't read the link I gave above, which points directly to
the kernel documentation on tmpfs. Here's the link again:

http://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt

> Anyway, I prefer not using swap at all.

I'm *generally* of the same opinion, but I budge here and there. I try
to have enough RAM in my various systems that I can build chromium and
libreoffice without things getting shoved to swap. (Heh. There's a
losing battle, especially when I parallelize stuff so much. And have
you seen the RAM consumed by ld in chromium's final link stages?)

> And I have better use for physical memory than holding some
> more-or-less statical data...

This is *exactly* what swap is for.

http://kerneltrap.org/node/3000

If you have, e.g. five terabytes of swap space and five terabytes of
RAM, and you set vm.swappiness to 0, your swap space will never get
touched. (Unless you somehow manage to consume all your RAM.)

In such a scenario, it'd be like not having any swap at all.

With that in mind, whether or not you have any swap, your only
sacrifice is how much space on a block device you sacrifice for a swap
partition. With the exception of some virtual machines, none of my
systems have drives smaller than 160GB. Discount laptops and mobile
devices, and none of my systems have drives smaller than 500GB. One
can easily throw 1GB of disk at swap (which then never gets used) and
not notice it in filesystem volume; I have running ext* filesystems
with more intrinsic overhead than that.

[snip]

-- 
:wq

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Neil Bothwick]

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

On Mon, 28 May 2012 21:24:59 +0200, Jarry wrote:

> > But why would you want to?  
> 
> I do not see any advantage in having /run on tmpfs.

Even though you have had several benefits explained to you? Files in /run
have to be available and writeable at all times from early boot onwards,
using a hard disk filesystem cannot guarantee this.

> > will be automatically moved to your swap partition if doing so
> > benefits your system.  
> 
> I'm not sure it is true. I have read somewhere that tmfps is
> never moved to swap.

You can justify anything you like with something you have read somewhere.
However, if you read the kernel docs on tmpfs you'll see

"tmpfs puts everything into the kernel internal caches and grows and
shrinks to accommodate the files it contains and is able to swap
unneeded pages out to swap space. It has maximum size limits which can
be adjusted on the fly via 'mount -o remount ...'"


-- 
Neil Bothwick

Barth's Distinction:
There are two types of people: those who divide people into two types, and
those who don't.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Neil Bothwick]

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

On Mon, 28 May 2012 20:31:39 +0200, Jarry wrote:

> But I'm still missing answer for my second question:
> 
> >> Q2: Can I turn this "/run in tmpfs" feature off?  

Of course you can, you have the source. However, it appears that no one
has implemented that particular feature for you yet. Maybe it is because
they have better things to do that move 300KB of files from the kernel's
caches to a disk filesystem from where it will be loaded into the
kernel's caches. That's the key point, that you don't actually save
memory by moving the files to a disk unless you are REALLY low on memory,
and then you have bigger things to worry about.


-- 
Neil Bothwick

This tagline is baroque; please call Bach.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] How can I control size of /run (tmpfs)?

[Pandu Poluan]

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

On May 29, 2012 12:53 AM, "pk" <peterk2@coolmail.se> wrote:
>
> On 2012-05-28 05:44, Pandu Poluan wrote:
>
> > But my newer servers has /run (and its children) from the get go,
because I
> > think it kind of makes sense. Even though they're udev-free.
>
> Hm... what is using /run instead of /var/run? I thought it was (newish)
> udev itself and things like systemd that uses /run instead of
> /var/run... just curious.
>
> Best regards
>
> Peter K
>

Nothing that I know of, then. But I  thought if sometime later down the
road some braindead dev assumes that everyone uses udev and hardwired
his/her package to assume /run exists, I'm covered :-)

Rgds,

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