[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

On Wed, Apr 13, 2011 at 10:51:50AM +0100, Philip Hands wrote:
> On Tue, 12 Apr 2011 13:51:09 +0200, Michael Biebl <biebl@debian.org> wrote:
> > I don't think symlinking /tmp to /run would be a good idea, as one could fill up
> > /tmp (accidentaly)  pretty quick.
> > If we want to make / ro, then a separate tmpfs for /tmp looks like a better idea
> > to me.
> While were about this, for installs where the users select multiple
> partitions we currently create a separate /tmp partition.
> This strikes me as suboptimal, since one could use the disk space
> allocated to /tmp as extra swap and then allocate a tmpfs of that size
> to be mounted on /tmp with no effect other than allowing the system to
> have access to more swap than it would have otherwise had (of course,
> that's probably more than it needs, so instead you could just save some
> disk space that would otherwise be left generally unused by overloading
> the swap usage with /tmp usage.
> Therefore, in the multi-partition setup, I think we should also default
> to having /tmp on tmpfs.

Sounds like a great idea.  I'd extend it to any setups with a swap.

Tmpfs is a lot faster than regular filesystems: it doesn't have to care
about preserving the data's integrity after a crash and thus has no
barriers, journaling, fsync().  When there's plenty of unused memory, the
data will not ever touch the disk, too -- gracefully getting written out
when there is a better use for memory it takes.  Since most files in /tmp/
are very short lived, it's a good optimization.

1KB		// Microsoft corollary to Hanlon's razor:
		//	Never attribute to stupidity what can be
		//	adequately explained by malice.

Attachment: signature.asc
Description: Digital signature

Reply to: