FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 05-26-2012, 09:47 PM
Nikos Chantziaras
 
Default How can I control size of /run (tmpfs)?

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.
 
Old 05-26-2012, 10:17 PM
Dale
 
Default How can I control size of /run (tmpfs)?

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"
 
Old 05-26-2012, 10:34 PM
Neil Bothwick
 
Default How can I control size of /run (tmpfs)?

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...
 
Old 05-26-2012, 10:45 PM
Michael Mol
 
Default How can I control size of /run (tmpfs)?

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
 
Old 05-26-2012, 11:17 PM
Dale
 
Default How can I control size of /run (tmpfs)?

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"
 
Old 05-26-2012, 11:21 PM
Alan McKinnon
 
Default How can I control size of /run (tmpfs)?

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
 
Old 05-26-2012, 11:23 PM
Alan McKinnon
 
Default How can I control size of /run (tmpfs)?

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
 
Old 05-27-2012, 12:15 AM
Dale
 
Default How can I control size of /run (tmpfs)?

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"
 
Old 05-27-2012, 02:30 AM
Pandu Poluan
 
Default How can I control size of /run (tmpfs)?

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,
 
Old 05-27-2012, 03:06 AM
Dale
 
Default How can I control size of /run (tmpfs)?

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"
 

Thread Tools




All times are GMT. The time now is 11:51 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org