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 RAM. 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
signature.asc
Description: This is a digitally signed message part
