Message-ID: <alpine.LSU.2.11.1607241226300.2694@eggly.anvils>
Date:	Sun, 24 Jul 2016 13:17:25 -0700 (PDT)
From:	Hugh Dickins <hughd@...gle.com>
To:	Ritesh Raj Sarraf <rrs@...ian.org>
cc:	Christoph Rohland <cr@....com>, Hugh Dickins <hughd@...gle.com>,
	linux-mm@...ck.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: tmpfs ability to shrink and expand

On Mon, 25 Jul 2016, Ritesh Raj Sarraf wrote:
> 
> I am writing to you because you are listed as Maintainers for the tmpfs file
> system in the Linux kernel.
> 
> 
> Recently, I have had a bug in a general purpose application, where it ran out of
> space in $TMPDIR. As is common, these days, most people vote for /tmp on tmpfs,
> for obviously good reasons (performance, efficiency etc).
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831998

I think the problem is not so much with tmpfs itself, as with tmpfs
defaulting to a smaller size (half of RAM) of filesystem than would
be common on disk.  You would see the same problems with a 3.7G
disk partition mounted on /tmp; but tmpfs is easier to resize.

Looks like it didn't need much more space, try
$ sudo mount -o remount,size=4G /tmp

Or, perhaps it's just that something else left its forgotten junk
behind in /tmp, and you need to do some cleanup.

> 
> 
> On bringing this bug, and the topic of "TMPDIR on tmpfs" on Debian-Devel,
> there's one comment which wasn't clear to me. Hence this email to you.
> 
> Even in the description below about tmpfs, it says, "..... to accommodate the
> files it contains and is able to swap unneeded pages out to swap space."

It writes of growing and shrinking there, to distinguish the behavior of
tmpfs from that of the original ramdisks we had in v2.4: where the maximum
RAM was assigned to them at startup IIRC.  Then ramdisks were changed to
allocate on demand during v2.6.  But ramdisks have never used swap, so
cannot shrink their RAM use after it has been allocated.

And yes, it is confusing to write of growing and shrinking, when this
growth and shrinkage in RAM use makes no difference to the filesystem
size itself: that limit remains the same throughout, unless you choose
to change it with a remount, as suggested above.

> 
> When we say "swap unneeded pages out to swap space", as I understand, what is
> being referred as "Swappable" here is any process in the kernel's namespace. And
> not referring to processes associated with /tmp ? Because those mostly will be
> active processes.

No, it's not talking about processes there.  Under memory pressure
page reclaim uses swap for storing pages of process anonymous memory,
and for storing pages of tmpfs file memory, until it's needed in RAM again.
Similar mechanism is used for paging in both cases, and all these pages are
tracked on the same lists, but processes and files are swapped independently.

> 
> The way I observed, it looks like whatever "/tmp on tmpfs" is capped at, from
> the VFS point of view, is the standard limit for processes accessing files in
> /tmp. And that file system view and limitations won't change (in effect to other
> processes being swapped or not).

Correct, the use of swap does not affect the filesystem size limit at all.

Hugh

> 
> Consider this example:
> 
> rrs@...tzpah:~$ df -h /tmp/
> Filesystem      Size  Used Avail Use% Mounted on
> tmpfs           3.7G  3.7M  3.7G   1% /tmp
> 
> rrs@...tzpah:~$ dd if=/dev/zero of=/tmp/foo.img bs=1M count=4000
> dd: error writing '/tmp/foo.img': No space left on device
> 3691+0 records in
> 3690+0 records out
> 3869605888 bytes (3.9 GB, 3.6 GiB) copied, 1.12808 s, 3.4 GB/s
> 
> rrs@...tzpah:~$ free -m
>               total        used        free      shared  buff/cache   available
> Mem:           7387        1882        4396         213        1108        4991
> Swap:          8579         109        8470  
> 
> 
> Here's the description of tmpfs from the latest
> linux/Documentation/filesystems/tmpfs.txt
> 
> 
> ============================================================
> Tmpfs is a file system which keeps all files in virtual memory.
> 
> 
> Everything in tmpfs is temporary in the sense that no files will be
> created on your hard drive. If you unmount a tmpfs instance,
> everything stored therein is lost.
> 
> tmpfs puts everything into the kernel internal caches and grows and
> shrinks to accommodate the files it contains and is able to swap
> unneeded pages out to swap space. It has maximum size limits which can
> be adjusted on the fly via 'mount -o remount ...'
> 
> If you compare it to ramfs (which was the template to create tmpfs)
> you gain swapping and limit checking. Another similar thing is the RAM
> disk (/dev/ram*), which simulates a fixed size hard disk in physical
> RAM, where you have to create an ordinary filesystem on top. Ramdisks
> cannot swap and you do not have the possibility to resize them. 
> 
> Since tmpfs lives completely in the page cache and on swap, all tmpfs
> pages will be shown as "Shmem" in /proc/meminfo and "Shared" in
> free(1). Notice that these counters also include shared memory
> (shmem, see ipcs(1)). The most reliable way to get the count is
> using df(1) and du(1).
> 
> ================================================================
> 
> - -- 
> Ritesh Raj Sarraf | http://people.debian.org/~rrs
> Debian - The Universal Operating System
> -----BEGIN PGP SIGNATURE-----
> 
> iQIcBAEBCgAGBQJXlQsoAAoJEKY6WKPy4XVpgCQP/RRaH8IGhUTQdjF8ao00rPXu
> RPo6ORs03Xn8E6zBP9qZbc2zv0FKTBzM9daTyLDRLzTaF91/eOlR6NQk0Gi6B+66
> RO2j7/F4OXs/Axp9Yx8LU0aTUt/A9MV8ugqPaaPRgfgVhdwPVD3zi5pP0uZAwpub
> fGicjop5vB+lv6PePioDRVOous9eomlI374PF6rP6kE2MSQSqbc+Yw4g8MC7SGZX
> Xja6OwOvGQTFkbQiT0M4BOjfKEM5S6BI4Vr7R/m4ivkDCj/dJONXQ05Escc8zDuQ
> yI5Rv39psWDxqTqnSPbENbSNTKw8KbswStgQUN66k/JpRQNNl3C+vLA0a5DWB5pQ
> q2mSFp66ynGF6DDhlMZOvHpammhecfZpcbFvGBXikuy193SXZfT+k11FJmSSJiVE
> Q4Tu6JvhADnGpfA07J9PjzV8kRsv9IdAgvFzWUsQeAi8/73ClOl3E7WHkN/zcdvO
> 5UkOne7h5hJjBNZD3pboQ2To9Wc4qeUWsdC8uHPN0h90fLp3oHA1v4JsraQ/MdbS
> yDozCgfZ7s/M4/V20OWJ+LlWohdhkeEHKHtZVabPqXpKSpU5UkvWg458Tnlzct85
> +/WMVztaF3OKsNb+CiSD0nLuLLi7Gu4TxS6JLZQEaJt/+XET7+mXPjou0g0MVg0X
> FGEVOJOwFNtQibJY70Qu
> =lCVO
> -----END PGP SIGNATURE-----
> 
> 

Powered by blists - more mailing lists