> I will work on improving the performance of NFSv2 and fixing bugs that
> exist on the server side.
How do you intend to improve performance? Are you thinking of anything
specific that the current implementation doesn't do or does only badly?
Or is it a more generic intention to look into possible problems?
Its a generic intention. Since the bug related to this also says in the more generic sense. Have to look at the possibilites. More over RFC too provides few specifications to improve performance. This includes going through the specification and implementing the unimplemented parts.
> This includes adding NFS Filesystem model which implements filesystem
> organization.
What's that?
NFS specification says NFS client specifies its own filesystem model to represent the filesystem hierarchy i.e directories and files organization. It is implemented for NFSv2, but this stage includes fixing some parts like the one you have asked for i.e "rm -r exampledir/" problem(details in other mail), and providing additional features required for NFSv3.
> This stage also includes completing the support for the Mount protocol
> which is employed to mount a filesystem and create handles to access
> files on it.
What is it missing currently? Or is that what you describe below?
(Pardon my ignorance...)
Needs a thorough look at the currect implementation, code and specifications to give full details. I am working on it. I will list them as soon as I finish it. It may be the cause for the above said error too.
> All the NFS server procedures(its nearly a misnomer since server
> procedures are actions that a client may take on files residing on a
> server) are implemented.
You mean you intend to implement them?
Yeah.
> Some of them include null, getattr, setattr, root, lookup, statfs,
> readdir etc which are not present in the current implementation but
> part of the NFS's Remote Procedure Calls(RPC).
Could you give a short summary what these do?
Hey I am sorry. I have put the words wrongly here. Actually I meant looking at which of these are not implemented and implementing them. Back when I was writing the proposal I had hardly 1 or 2 days and I was not able to check for all of those things in the code and write speicfically. So I wrote in this generic way.
Anyhow here are the details of each of them
Null - Dummy procedure provided for
testing purposes.
getattr - Retrieves the
attributes of a file on a remote server.
setattr - Sets the attributes
of a file on a remote server.
root - This procedure
was originally defined to allow a client to find the root of a remote system
lookup - Returns the file handle of a
file for the client to use.
statfs - Provides to
the client general information about the remote file system, including
the size of the file system and the amount of free space remaining.
readdir - Reads the contents of a directory.
> The next stage of this project starts with implementing the core
> NFSv3 protocols.
[...]
> 3. Additional file attributes in many replies including fourth set
> of permission bits
Is that really related to NFSv3?...
Not exactly to NFSv3. But I have put this in this stage because it requires an in depth knowledge of NFS file handling mechanisms. So I thought I would have gained enough experiences while implementing NFSv2 features and this could be done quickly at this stage.
Anyways, this is only meaningful if both the client *and* the server
understand the Hurd extensions -- as you said that we don't have a
usable server anyways, I would leave it out for now...
Ok fine.
> 6. Improved file locking support with GNU/Linux
Does NFSv3 provide improvements in this regard?
No same explaination as above.
I do experience many locking problems myself, but I'm not sure where
they come from. It could be deficiencies in the NFS client, but it also
might be just the general locking problems we have on the Hurd...
Also, I had some locking problems as well when running a GNU/Linux NFS
client with the GNU/Linux server for testing -- so I wonder whether the
problem is actually on the server side...
Oh Ok.
> Other Hurd specific functions such as adding support for 1.
> Changing a file's author 2. Passive translators
>
> are also implemented.
You mean you want to implement these as well? Well, see above regarding
fourth permission bit...
I did not get you.
> With these features of NFS ready, the next stage of the project is
> to test these implementations with the GNU/Linux servers
You will have to test all the changes you make with GNU/Linux servers
anyways, as we have no other available... :-)
Ok :)
> 2. Analysis and Design I ( May 26th ? June 1st ) Involves the
> analysis of existing code. Interacting with the mentor, the Hurd
> community and other people involved in implementation of NFS on
> other platforms to draw the exact design of the proposed NFSv2
> implementation. Preparing algorithms required for NFSv2
> implementation completion.
Well, the NFSv2 part is about fixing some problems and filling in some
gaps in the existing implementation... I don't think there is any
serious design work involved in that.
Fine I will make necessary changes.