> 2014/1/17 Frank Filz <ffilzlnx@xxxxxxxxxxxxxx>: > > This looks wonderful and will be useful to the Ganesha user space NFS > > server also. > > > > I do have a couple questions. > > > > 1. How will this interact with the idea of private locks from the > > patch set Jeff Layton has been pushing? > > They don't touch each other. > > > > > 2. If a process opens multiple file descriptors with deny modes, will > > they conflict with each other (which is the behavior we will want for > Ganesha). > > Yes, a deny mode is associated with file descriptor - so, it will conflict with any > other access/deny modes of file descriptors from any process. > > > > > 3. Is there any functionality to upgrade or downgrade the access and > > deny modes (thinking in terms of NFS v4 support of OPEN upgrade and > > OPEN_DOWNGRADE operations). > > The proposed patchset doesn't allow to change deny modes after an open is > done. But we can add a functionality to let flock syscall change deny modes > as on option. Yes, that would be good. NFS v4 allows upgrade/downgrade of acces/deny modes (hmm, changing access mode would be trickier, but we need to be able to upgrade/downgrade those as well as deny modes...). It could still be done with an fcntl. I don't know if any NFS clients make use of upgrade/downgrade (I do know there are pynfs tests for it). Interestingly, upgrade/downgrade would be a solution to Ganesha's problems with POSIX locks being dumped on any file descriptor close since we could change the access mode as needed rather than needing to close and open the file. Frank -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
