Date: Wed, 19 May 2021 14:24:13 +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-IuLQIOrrYb@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 Rick Macklem <rmacklem@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rmacklem@FreeBSD.org --- Comment #21 from Rick Macklem <rmacklem@FreeBSD.org> --- A lack of any cache consistency guarantees is a major limitation and I tend to agree with Kirk that this should not be recommended practice. If it works for you, that's fine, but others would not understand the limitations of not having cache consistency and that would probably result in bug reports related to it. When I wrote the packrats code, cache consistency was maintained by the NFSv4 delegation. Although the code basically worked (I had not written the recovery code needed after a client reboot), I left the bits to rot because I did not think it was widely useful. I may eventually revisit that, since I can see cases where it could be useful. My intent was to handle laptops mounting through wifi/wan connections better, since those are often high latency connections. I suspect that some of your performance improvement is a result of the lack of cache consistency. For example, flushing of all written data to the server upon close(2) can be a big performance hit, but is required for close->open consistency. --> I honestly do not know how the Linux fscache code works, but I suspect that some variant of cache consistency is maintained by it. Another issue is that the comment in the bugs section of the mount_unionfs man page still applies (and is in caps). I don't know the details w.r.t. how unionfs is broken, but if it were easy to fix, someone would have done so. I do know that people report issues w.r.t. using unionfs on an NFS mount and I simply point out to them that it is broken. It does not make much sense to implement a new feature on top of a broken one, imho. kib@ is probably the only person who knows what the breakage in unionfs is and what needs to be done to fix it. rick ps: I don't think comments like "the one and only" are appreciated in the context you used it. --=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-IuLQIOrrYb>