Date: Mon, 16 Mar 2026 16:30:32 -0700 From: Mark Millard <marklmi@yahoo.com> To: Alan Somers <asomers@freebsd.org>, Garrett Wollman <wollman@bimajority.org> Cc: freebsd-stable@freebsd.org Subject: Re: ZFS deadlocks/memory accounting issues Message-ID: <d4375cac-752b-4a7a-8927-28a8d0cc79d4@yahoo.com> In-Reply-To: <CAOtMX2gpNQH9hpCnRP%2Bm5kBJDMf5O3MSHgzPVjBKEObyL8bjdw@mail.gmail.com> References: <27064.27391.224476.910636@hergotha.csail.mit.edu> <CAOtMX2gpNQH9hpCnRP%2Bm5kBJDMf5O3MSHgzPVjBKEObyL8bjdw@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
On 3/16/26 14:08, Alan Somers wrote: > On Mon, Mar 16, 2026 at 2:41 PM Garrett Wollman <wollman@bimajority.org> wrote: >> >> . . . >> -GAWollman > > I once saw a similar bug. In my case I had a process that mmap()ed > some very large files on fusefs, consuming lots of inactive pages. > And when the system comes under memory pressure, it asks ARC to evict > first. So the ARC would end up shrinking down to arc_min every time. > In my case, the solution was to set vfs.fusefs.data_cache_mode=0 . I > suspect that similar bugs could be possible with UFS or tmpfs, if they > have giant files that are mmaped(). ZFS is documented to have the property: "This approach provides coherency between memory-mapped and IO access as the expense of wasted memory due to having two copies of the file in memory and extra overhead caused by the need to copy the contents between the two copies." (Chapter 10, page 548, last bullet item of the 2nd edition of the design and implementation book.) > > A less effective workaround was to set vfs.zfs.arc.min to some > reasonable value. That can prevent ARC from shrinking too far. You > could try that. > > Another thing you could try is to run "vmstat -o" when the system is > in the problematic state. That will show you which vm objects are > using the most inactive pages. > > Hope this helps, > -Alan > > -- === Mark Millard marklmi at yahoo.comhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d4375cac-752b-4a7a-8927-28a8d0cc79d4>