Hello all,
As a prelude to adding support in kNFS(lockd) to pass lock information via
the VFS interface I want to firsr propose some minor changes that will
enable us to have a single lock ownership space that is shared and enforced
at all nodes.
Currently lockd identified range locks with two fields fl_owner and fl_pid.
NFS code places a memory pointer (pointer to host structure representing
NFS client holding the lock) in fl_owner which works great in single node
NFS but breaks when we attempt to pass lock requests to an the underlying
distributed filesystem in the context of a clustered NAS head. This can be
easily fixed by filling fl_owner field with the IP address of the NFS
client requesting the lock, which is just a minor patch.
The patch above, however, does not fix all our problems as locks acquired
locally in the NFS server nodes could collide with NFS locks. Currently,
the fl_owner field for locks acquired via the local file system is filled
with another memory pointer (i.e. current->files). This also breaks appart
when using a distributed file system. My proposal for this would be use a
local IP address to put in the fl_owner field of locks acquired locally in
a node.
These two patches cause no problem for current single node NFS servers and
enable Linux as a platform to support distributed filesystems and NFS
serving simultaneously and correctly.
I would like to get your feedback on this proposal and if accepted as it is
I will later follow with patches for current versions of the kernel NFS.
Regards, Juan
Hey, how about cc'ing either me or linux-fsdevel when discussing file
locking in the future as described in MAINTAINERS?
Your idea doesn't work because we need fl_owner to be the files_struct
for local locks. It also doesn't work because IPv4 is not the only
protocol which NFS runs over.
--
Revolutions do not require corporate support.
Sure I can also cc that list.
Regarding your comments I do have a test implementation that takes care of
storing files_struct for local locks so this is not a problem.
(By the way, the use of that field to store that seems very bad idea imho)
Regarding IPv4 not being the only protocol, I would say yes that is a
problem and in fact I the one solution to this would be to enlarge
fl_owner field, but thats a lot of work.
In any case my main problem is to find a unique node identifier that is not
bound to the underlying protocol you are using without requiring
clustering between the nodes that are participating as part of nas head,
suggestions on how to create a clean portable solution are welcome.
Juan
|---------+---------------------------->
| | Matthew Wilcox |
| | <[email protected]|
| | > |
| | Sent by: |
| | <willy@http://www.linux.|
| | org.uk> |
| | |
| | |
| | 10/31/02 01:08 PM|
| | |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------|
| |
| To: Juan Gomez/Almaden/IBM@IBMUS |
| cc: [email protected], [email protected] |
| Subject: Re: Proposal for new lock ownership scheme to support NFS over distributed filesystems |
| |
| |
>------------------------------------------------------------------------------------------------------------------|
Hey, how about cc'ing either me or linux-fsdevel when discussing file
locking in the future as described in MAINTAINERS?
Your idea doesn't work because we need fl_owner to be the files_struct
for local locks. It also doesn't work because IPv4 is not the only
protocol which NFS runs over.
--
Revolutions do not require corporate support.