Yea, a good point about Ganesha holding fd open. If we don’t hold fd open for
getattr/setattr, NFS v4 should be able to function well without holding fd open.
The idea of using setlease would still be good for NFS v3 (or any NFS v4
clients that use special stateids to do anonymous I/O). One thing we could do
is have FSAL_VFS do a setlease on each global fd it opens. It then could use an
avltree to map fd back to obj_handle. It actually does not need to notify
MDCACHE – EXCEPT for the counting of open fd (which we need to make NOT
something that MDCACHE needs to manage the count of, it just needs to see the
count so it can reap open fd).
On the other hand, if we separate the open fd LRU from the object cache LRU as
I have proposed, in a multi-protocol environment the open fd LRU could be made
much more aggressive so open global fd get closed much quicker after use.
Frank
From: pradeep.tho...@gmail.com [mailto:pradeep.tho...@gmail.com] On Behalf Of
Pradeep
Sent: Thursday, March 8, 2018 7:37 PM
To: Frank Filz <ffilz...@mindspring.com>
Cc: DENIEL Philippe <philippe.den...@cea.fr>; nfs-ganesha-devel
<nfs-ganesha-devel@lists.sourceforge.net>
Subject: Re: [Nfs-ganesha-devel] Multiprotocol support in ganesha
Hi Frank,
I think there are cases where a touch/chmod on a file causes it to be opened
forever in ganesha (until we are over the FD limit). This will prevent other
applications such as Samba from opening the file and sharing it through SMB
protocol to windows clients. Samba uses SETLEASE to get notified if other
applications open the file. Ganesha also may have to do something similar to
get notified and close cached FDs. The challenge is to map FD to MDCACHE object
so that it can call close() on that object. One way to map FD to a path (using
readlink) and then convert that to export and relative path. Given export and
relative path, FSAL could return a key for that which can be used to lookup the
object in MDCACHE. Is there a better way?
Here is the relevant Samba code that implements SETLEASE and signal handler:
https://github.com/samba-team/samba/blob/master/source3/smbd/oplock_linux.c
Thanks,
Pradeep
On Wed, Mar 7, 2018 at 7:18 AM, Frank Filz <ffilz...@mindspring.com
<mailto:ffilz...@mindspring.com> > wrote:
Unfortunately out in the real world, people want to mix POSIX and Microsoft
semantics…
So we do the best we can.
I wonder how much of the multi-protocol use falls into two camps:
1. Simple file sharing, for example, I run Virtual Box on a Windows
machine to get Linux VMs. I mount my Windows “My Documents” into the Linux VM
so I can easily pass files back and forth. Share reservations work and prevent
Linux from trampling things if Microsoft Word happens to have a file open.
2. Some kind of database application with clients on multiple platforms.
Such application will use appropriate synchronizing operations including byte
range locks in a way that does not depend on any of the peculiarities of POSIX
or Microsoft semantics.
Yea, we can try to make things like delete of open files work as best as
possible, but either of those two use cases won’t have any really big surprises
if the integration for a peculiarity like deleting an open file isn’t perfect.
Now one use case that may not go so well is an application that uses lock files
to indicate which client or process is active…
I’ve seen folks paranoid that POSIX byte range locks are only advisory, but
outside of a program bug, if a POSIX app and a Windows app are both using byte
range locks to protect records they are changing, it doesn’t matter that POSIX
thinks they are only advisory… Of course a server CAN enforce the range locks
(and NFS v4 even supports this idea), and yea, that will break a POSIX app that
thought it didn’t actually need to respect the locks.
I think overall Ganesha does a pretty good job. There are places where it can
do better.
While talk of having an SMB front end to Ganesha are fun, I doubt we will ever
do that, and I don’t think it’s necessary to have sufficiently good integration
to cover 99.9% of the possible multi-protocol use cases.
Frank
From: DENIEL Philippe [mailto:philippe.den...@cea.fr
<mailto:philippe.den...@cea.fr> ]
Sent: Wednesday, March 7, 2018 6:28 AM
To: Pradeep <pradeeptho...@gmail.com <mailto:pradeeptho...@gmail.com> >;
nfs-ganesha-devel <nfs-ganesha-devel@lists.sourceforge.net
<mailto:nfs-ganesha-devel@lists.sourceforge.net> >
Subject: Re: [Nfs-ganesha-devel] Multiprotocol support in ganesha
Hi,
from a "stratospheric" point of view, I see a potentially big issue ahead for
such a feature : FSAL has been designed to be quite close to POSIX behavior,
CIFS follows the Microsoft File System semantics, which is pretty different
from POSIX.
My experience with 9p integration in Ganesha shows some issues in POSIX corner
cases (like "delete on close" situations), I can't imagine what integrating a
CIFS support would mean.
Years ago, Tom Tapley came to bake-a-thon (this was a few months after he
joined Microsoft Research) and he talked about issues met by Microsoft to
implement a NFSv4 support, because of Microsoft semantics. He found many, but
was quite optimistic. Current state : Windows has no NFS support and code
developed at CITI (e.g. NFSv4 clients for Windos) were not pushed to Windows.
Microsoft is not POSIX and POSIX is not Microsoft. They live in two very
different worlds, and it's probably better so ;-)
Regards
Philippe
On 03/06/18 18:20, Pradeep wrote:
Hello,
Is there plans to implement multiprotocol (NFS and CIFS accessing same
export/share) in ganesha? I believe current FD cache will need changes to
support that.
Thanks,
Pradeep
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
<mailto:Nfs-ganesha-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
