Date: Sun, 15 Oct 2017 11:41:14 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 223015] [tmpfs] tmpfs does not support sparse files Message-ID: <bug-223015-3630-idogsuoHvv@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-223015-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-223015-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223015 Konstantin Belousov <kib@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kib@FreeBSD.org --- Comment #1 from Konstantin Belousov <kib@FreeBSD.org> --- Well, tmpfs does support spare files. What you reported is indeed the wrong behavior, but it is caused not by supposed lack of support for spares, but due to wrong code what tries to av= oid OOM situations due to over-committing the file backing for tmpfs files. See sys/fs/tmpfs_subr.c, functions tmpfs_pages_check_avail() and functions tmpfs_mem_avail() and tmpfs_pages_used() referenced from there. In particular, tmpfs_mem_avail() is completely wrong, it mis-interprets v_free_count. I think that tmpfs should only check the current page usage by specific mou= nt point against per-mount point limit, if any. Trying to formulate a limit against some formula involving v_free_count and other VM metrics cannot wor= k, due to the VM algorithms. The main reason is that we support paging memory= to the backing store, so v_free_count indicates wasted memory (as opposed to t= he free or free-able memory in the common sense of the word). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-223015-3630-idogsuoHvv>