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

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

On Thu, 2016-07-21 at 21:22 +0530, Ritesh Raj Sarraf wrote:
> On Thu, 2016-07-21 at 15:42 +0200, Vincent Lefevre wrote:
> > On 2016-07-21 15:24:10 +0200, Philip Hands wrote:
> > > It's configurable.
> > > 
> > > See TMPFS_SIZE in /etc/defaults/tmpfs
> > 
> > If you mean /etc/default/tmpfs, it doesn't work with systemd
> > (as documented), and there's the global problem with swap.
> And I was thinking of asking the same to the systemd maintainers. So thanks
> for
> mentioning this. Though I wish systemd honored values from these files.

So, as I understand it, systemd inherits the size value from, either /etc/fstab
or the kernel defaults (which is 50% of RAM).

And given that /tmp in Debian doesn't have a default listing in /etc/fstab, the
defaults would be picked up from the kernel defaults. Which would still be
capable of making many applications break, on a machine with lesser amount of

BTW, is there an equivalent of, whats documented in /etc/default/tmpfs about:
TMPFS_SIZE=80%VM, in systemd ? I looked into tmpfs mount manpage section and it
does not talk about VM.

@Vincent: I agree with the pain about swap that Linux brings in. The assumption
everyones making is that faster block devices (SSDs mostly) will mitigate the
problem. And to a large extent it seems to have done that.
But I still have read [1] users report the bug existent, even on Android/Linux,
where I assume they are more commonly using Flash storage. 
Which confirms the arguments that slow rotational media is just part of the
problem (the bug provoker, as I like to put), the real problem lies in how I/O
scheduling works in Linux.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=12309#c639

Given the large number of mailing lists I follow, I request you to CC
me in replies for quicker response

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: