Excerpts from Jan Spakula's message of Thu Feb 12 09:22:00 +0100 2009:

Excerpts from Jan de Groot's message of Thu Feb 12 08:59:41 +0100 2009:

...

...

I interested to make Arch Linux suitable for use with a /var/run and /var/lock that are mounted as tmpfs. But this also helps, in the case that not mounted as tmpfs, to make more simple "purge function" for these directories at rc.sysinit step.

In my case this is "just for fun!", but other users can be benefited by this, for example "netbook users". If this requires patching so many packages, and given the fact

On Thu, 2009-02-12 at 05:51 -0200, Gerardo Exequiel Pozzi wrote: that /var/run on tmpfs is not default in archlinux, maybe you should try building /var/run from an initial directory or something like that. This is also what I use for my OpenBSD router which runs from compactflash and has /var mounted on ramdisk.

I have a setup on my netbook where the whole /var is mounted as tmpfs and rsynced from and to real directory (/var-sync in my case) on boot/shutdown. Patches to rc.sysinit and rc.shutdown follow. [Note that whenever you update initscripts, you need to patch at least rc.shutdown before rebooting :)]

Well apparently attachments are scrubbed, so here you go http://rafb.net/p/ePKlct55.html http://rafb.net/p/yDQSPc95.html Advantages are mainly on netbooks, which have limited number of writes to their ssd drives, this eliminated a big source of uncontrolled writes.

Jan Spakula wrote:

Excerpts from Jan Spakula's message of Thu Feb 12 09:22:00 +0100 2009:

...

Excerpts from Jan de Groot's message of Thu Feb 12 08:59:41 +0100 2009:

...

On Thu, 2009-02-12 at 05:51 -0200, Gerardo Exequiel Pozzi wrote:

...

I interested to make Arch Linux suitable for use with a /var/run and /var/lock that are mounted as tmpfs. But this also helps, in the case that not mounted as tmpfs, to make more simple "purge function" for these directories at rc.sysinit step.

In my case this is "just for fun!", but other users can be benefited by this, for example "netbook users".

If this requires patching so many packages, and given the fact that /var/run on tmpfs is not default in archlinux, maybe you should try building /var/run from an initial directory or something like that. This is also what I use for my OpenBSD router which runs from compactflash and has /var mounted on ramdisk.

I have a setup on my netbook where the whole /var is mounted as tmpfs and rsynced from and to real directory (/var-sync in my case) on boot/shutdown. Patches to rc.sysinit and rc.shutdown follow. [Note that whenever you update initscripts, you need to patch at least rc.shutdown before rebooting :)]

Well apparently attachments are scrubbed, so here you go http://rafb.net/p/ePKlct55.html http://rafb.net/p/yDQSPc95.html

Advantages are mainly on netbooks, which have limited number of writes to their ssd drives, this eliminated a big source of uncontrolled writes.

Hi Jan Spakula, Check the rsync manpage for the --inplace parameter, this reduces the amout of writes to the destination, ideal for files that grows "in appended form" like most of /var/log files. But again read the manpage for what are the _risk_ of using this ;) -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

On Thu, 2009-02-12 at 20:42 -0200, Gerardo Exequiel Pozzi wrote:

I know that Arch Linux don't support these directories as tmpfs or "all empty" by default, but with these trivial patches to rc-script can support it. Not only this is usefull for "tmpfs", maybe for other things.

Having initscripts for daemons just to create this path (policykit) or let other packages create the required directories instead (hal that creates policykit directories?) isn't the most trivial thing in my opinion.

Aaron Griffin wrote:

On Fri, Feb 13, 2009 at 1:42 AM, Jan de Groot wrote:

...

On Thu, 2009-02-12 at 20:42 -0200, Gerardo Exequiel Pozzi wrote:

...

I know that Arch Linux don't support these directories as tmpfs or "all empty" by default, but with these trivial patches to rc-script can support it. Not only this is usefull for "tmpfs", maybe for other things.

Having initscripts for daemons just to create this path (policykit) or let other packages create the required directories instead (hal that creates policykit directories?) isn't the most trivial thing in my opinion.

Still, I think this had potential. We can already see that it would be useful on some netbooks, so I think it's a step in the right direction.

While this may be a non-trivial change, I do see the benefit, so I'd like to implement this _in theory_ at some point. So keep up the good work and we'll see where we can get with this. I'd recommend filing a feature request in the bug tracker

Thank you very much for good efforts. :) Well, in the case of non-trivial patch of PolicyKit, this apparently will become obsolete in the near future and will be replaced by a new implementation polkit [1] / eggdbus [2]. It is possible that the situation will change radically. I will create a feature request to the FS that globalized packages that are required to be friendly with the desired behavior. Like in the initial email. Again, thanks for your time, good luck ;) [1] http://lists.freedesktop.org/archives/polkit-devel/2009-January/000070.html [2] http://mail.gnome.org/archives/gtk-devel-list/2008-December/msg00059.html -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

Xavier wrote:

Now we already have 2 devs, JGC and Pierre who seem to be against this proposal, and who recommended you to just populate /var/run and others based on an initial directory. Then two users reported they were already using tmpfs with no problems. Jan Spakula posted his modified rc.sysinit and rc.shutdown, and Nicolas said he just wrote a separate rc script to do that syncing job. I am not against your proposal, but you did not make clear what its advantages are, and why it is worth the additional complexity?

As I said earlier, depending on how we interpret the standards of the FHS. And here I __apologize__, my English for write is not very good because it is not my native language, in fact I am using the google translator to help me (hehe), so if in any part of my message tone offense was not, not is my intention offend any user and your proposed solutions. [@] If the initial content of the /var/run must be completely empty at boot or must persist directories but not files. This can be seen in the behavior of various programs. Some create the appropriate directory in /var/run and work well, but fail if no other before. Some programs, when completed, left files in there, and others are "well educated" and delete its contents. So, here comes in the task of the startup script to delete those files. My personal interpretation is that the directories in there, are generated at runtime, and these can be eliminated without any problems. (Clearly this is not true, as I said above many programs fail) Well, therefore, the benefit of each program is responsible for creating the temporary directory, if that does not exist, it allows two things: * The contents of the directory can be deleted without any exceptions. * This directory can be mounted as tmpfs with the simple addition of a line in the fstab and also has the advantage of removing the need to erase the contents in the boot. This behavior of erase or not, could be controlled with a simple check fstab or switch in rc.conf (this also applies to /var/lock (1777) and the most problematic for deletion: the "Mr /tmp") * Any other purpose. [@] Ok that cleared, I will say this: The solution of copying temporal/run-time data of the /var/run for mounting this as tmpfs i do not think a clean solution, but if it works of course :) My idea behind this is that each program do its work to function properly. Thanks for your time ;) -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D