On Wed, 30 Oct 2024 at 17:15, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: > > > > > On Oct 30, 2024, at 10:55 AM, Cedric Blancher <cedric.blancher@xxxxxxxxx> wrote: > > > > On Tue, 29 Oct 2024 at 17:03, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: > >> > >>> On Oct 29, 2024, at 11:54 AM, Brian Cowan <brian.cowan@xxxxxxxxxxxxxxxx> wrote: > >>> > >>> Honestly, I don't know the usecase for re-exporting another server's > >>> NFS export in the first place. Is this someone trying to share NFS > >>> through a firewall? I've seen people share remote NFS exports via > >>> Samba in an attempt to avoid paying their NAS vendor for SMB support. > >>> (I think it's "standard equipment" now, but 10+ years ago? Not > >>> always...) But re-exporting another server's NFS exports? Haven't seen > >>> anyone do that in a while. > >> > >> The "re-export" case is where there is a central repository > >> of data and branch offices that access that via a WAN. The > >> re-export servers cache some of that data locally so that > >> local clients have a fast persistent cache nearby. > >> > >> This is also effective in cases where a small cluster of > >> clients want fast access to a pile of data that is > >> significantly larger than their own caches. Say, HPC or > >> animation, where the small cluster is working on a small > >> portion of the full data set, which is stored on a central > >> server. > >> > > Another use case is "isolation", IT shares a filesystem to your > > department, and you need to re-export only a subset to another > > department or homeoffice. Part of such a scenario might also be policy > > related, e.g. IT shares you the full filesystem but will do NOTHING > > else, and any further compartmentalization must be done in your own > > department. > > This is the typical use case for gov NFS re-export. > > It's not clear to me from this description why re-export is > the right tool for this job. Please explain why ACLs are not > used in this case -- this is exactly what they are designed > to do. 1. IT departments want better/harder/immutable isolation than ACLs 2. Linux NFSv4 only implements POSIX draft ACLs, not full Windows or NFSv4 ACLs. So there is no proper way to prevent ACL editing, rendering them useless in this case. There is a reason why POSIX draft ACls were abandoned - they are not fine-granted enough for real world usage outside the Linux universe. As soon as interoperability is required these things just bite you HARD. Also, just running more nfsd in parallel on the origin NFS server is not a better option - remember the debate of non-2049 ports for nfsd? > > And again, clients of the re-export server need to mount it > with local_lock. Apps can still use locking in that case, > but the locks are not visible to apps on other clients. Your > description does not explain why local_lock is not > sufficient or feasible. Because: - it breaks applications running on more than one machine? - it breaks use cases like NFS--->SMB bridges, because without locking the typical Windows .NET application will refuse to write to a file - it breaks even SIMPLE things like Microsoft Excel Of course the happy echo "hello Linux-NFSv4-only world" >/nfs/file will always work. > > Of course no one needs the gov customers, so feel free to break locking. > > > Please have a look at the patch description again: lock > recovery does not work now, and cannot work without > changes to the protocol. Isn't that a problem for such > workloads? Nope, because of UPS (Uninterruptible power supply). Either everything is UP, or *everything* is DOWN. Boolean. > > In other words, locking is already broken on NFSv4 re-export, > but the current situation can lead to silent data corruption. Would storing the locking information into persistent files help, ie. files which persist across nfsd server restarts? Ced -- Cedric Blancher <cedric.blancher@xxxxxxxxx> [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur
