Date: Mon, 23 Oct 2017 14:53:48 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 223015] [tmpfs] [patch] tmpfs does not support sparse files Message-ID: <bug-223015-3630-EvOjcsPlns@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 --- Comment #9 from Konstantin Belousov <kib@FreeBSD.org> --- (In reply to Keith White from comment #8) Let me explain it in full: 1. tmpfs should not try to use current counters of the active/inactive or f= ree queues, since they are irrelevant to the system ability to satisfy page requests. If page is needed, the queues are scanned and a usable page might appear even if there is no free pages or all swap space is used (e.g. we can write out dirty file page or reuse clean file page). 2. tmpfs should provide a global limit on the number of used pages, in fact= it already has it "-o size". The limit is compared against the maintained cou= nter of the supposedly used pages tm_pages_used. 3. Your problem is because tm_pages_used is too harsh. It just sums up all files sizes, while it really should only count file pages which were really written to. In other words, instead of adjusting tm_pages_used in tmpfs_reg_resize(), it should be adjusted in tmpfs_write(). [There is additional complication, see below]. 4. The tmpfs_mem_avail() should be removed. See item 1. The complication is due to the tmpfs using in-place mapping, i.e. the vm ob= ject which contains the pages with the file data, directly provides the pages us= ed for file mapping. This was highly desirable feature, because it avoids duplicating memory for the mmapped tmpfs files, and makes mmap zero-copy. Problem is, page faults in the sparcerly allocated mmaped file range instantiate the file pages, which must be accounted for in tm_pages_max. T= he tmpfs vm objects are already flagged so this is not too hard to do, just th= at you cannot limit the patch to fs/tmpfs only. This is my current opinion on the issue, hope this is clean enough. --=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-EvOjcsPlns>