Trond.Myklebust@xxxxxxxxxx wrote: > SSBkbyBtaW5kOyBpdCBpcyBjbGVhcmx5IHN0YXJ0aW5nIHRvIGJpdHJvdCBkdWUg > dG8gYW4gYWJzZW5jZSBvZiB1c2Vycy4NCk1haW50ZW5hbmNlIG9mIHVudXNlZCBjb2RlIGlzIGFj > dHVhbGx5IF9tb3JlXyBvZiBhIHBhaW4sIG5vdCBsZXNzLg0KDQpTbyB1bmZzZCBpcyBvbmUgc29s > dXRpb24uIEtlZXBpbmcgYSBWTSB3aXRoIGFuIG9sZGVyIHZlcnNpb24gb2YgdGhlDQpMaW51eCBr > ZXJuZWwgdGhhdCBzdGlsbCBzdXBwb3J0cyBORlN2MiBpcyBhbm90aGVyLiBWb2x1bnRlZXJpbmcg > dG8NCm1haW50YWluIHRoZSBjb2RlIGlzIGEgdGhpcmQuDQoN Which can be base64 decoded (why was it ever ENcoded?) to > I do mind; it is clearly starting to bitrot due to an absence of users. > Maintenance of unused code is actually _more_ of a pain, not less. > > So unfsd is one solution. Keeping a VM with an older version of the > Linux kernel that still supports NFSv2 is another. Volunteering to > maintain the code is a third. If I might ask, though, is the pain concentrated more on the client or the server side? NFSv2 server support seems a fairly simple matter of some old compatibility RPC calls. The main pain is the limited size of the file handle and (especially) readdir cookies. Client support is probably more complicated, as NFS's "stateless server" model puts the bulk of the complexity on the client, and you need a thicker layer of logic to translate the operations into a different vocabulary pf RPC calls. I don't think NFSv2 client support would be mourned much; trying to to use such an ancient limited machine as a file server seems stupid. It's NFSv2 server support that I, and I believe Larry, are interested in preserving, in order to provide services to ancient clients. The only real use of v2 client code is te test the server. -- 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
