Date: Wed, 19 May 2021 02:27:24 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 251363] use unionfs as a disk-cache for NFS [feature] Message-ID: <bug-251363-3630-SoPWeg5Gjf@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-251363-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-251363-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=3D251363 --- Comment #19 from Gunther Schadow <raj@gusw.net> --- I am certainly honored to be replied to by the one and only Kirk McKusick, = and of course I understand the cache consistency issue. HOWEVER, I am sure you = will also accept that the buffer cache is a very limited resource and generally = too small to hold a lot of binaries just in case. The truth is that /bin, /usr/bin, /lib and all that good stuff hardly never changes in a production system except for times of controlled upgrades. Therefore the argument that the UNIONFS cache would become stale is not rea= lly hard hitting. I think my approach has a very good purpose when and where applied with an understanding of the consequences. Finally, if you really wanted to do an unlimited cache that is kept consist= ent, then nothing should stop the addition of some additional update checks befo= re every access of the local cache on the source NFS, and likewise, writes cou= ld be written through to the NFS backend. In other words, NFS could have a loc= al unlimited size disk cache feature. But I doubt anyone would have fulfilled = my wish, so I went ahead and provided small improvements to the UNIONFS code to help me with my imperfect solution that's nevertheless good enough for me. --=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-251363-3630-SoPWeg5Gjf>