[email protected] wrote:
> We should probably aim to remove it entirely in the next 1-2 years.
> There is no place in today's world for a protocol that can only deal
> with a 2GB maximum file size...
Today's world includes a lot of yesterday's world.
I'm still running a SunOS 4.1.4 machine. Yes, it does real (dusty
deck) work; I just had to resurrect it when its HDD died.
I got to rediscover its 2 GB maximum FILESYSTEM size.
(When the hardware finally craps out for real, I'll probably
punt to QEMU. But I either have to add SunOS system call
emulation to QEMU, or run the whole OS under hardware emulation.)
Anyway, most of its files are actually on a Linux NFS server
with a proper RAID and backup system.
I'd kind of like to keep NFSv2 working, if you don't mind.
("I do mind; install unfsd" is perhaps a legitimate response.)
T24gTW9uLCAyMDEyLTEwLTE1IGF0IDA0OjA1IC0wNDAwLCBHZW9yZ2UgU3BlbHZpbiB3cm90ZToN
Cj4gVHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20gd3JvdGU6DQo+ID4gV2Ugc2hvdWxkIHByb2Jh
Ymx5IGFpbSB0byByZW1vdmUgaXQgZW50aXJlbHkgaW4gdGhlIG5leHQgMS0yIHllYXJzLg0KPiA+
IFRoZXJlIGlzIG5vIHBsYWNlIGluIHRvZGF5J3Mgd29ybGQgZm9yIGEgcHJvdG9jb2wgdGhhdCBj
YW4gb25seSBkZWFsDQo+ID4gd2l0aCBhIDJHQiBtYXhpbXVtIGZpbGUgc2l6ZS4uLg0KPiANCj4g
VG9kYXkncyB3b3JsZCBpbmNsdWRlcyBhIGxvdCBvZiB5ZXN0ZXJkYXkncyB3b3JsZC4NCj4gDQo+
IEknbSBzdGlsbCBydW5uaW5nIGEgU3VuT1MgNC4xLjQgbWFjaGluZS4gIFllcywgaXQgZG9lcyBy
ZWFsIChkdXN0eQ0KPiBkZWNrKSB3b3JrOyBJIGp1c3QgaGFkIHRvIHJlc3VycmVjdCBpdCB3aGVu
IGl0cyBIREQgZGllZC4NCj4gDQo+IEkgZ290IHRvIHJlZGlzY292ZXIgaXRzIDIgR0IgbWF4aW11
bSBGSUxFU1lTVEVNIHNpemUuDQo+IA0KPiAoV2hlbiB0aGUgaGFyZHdhcmUgZmluYWxseSBjcmFw
cyBvdXQgZm9yIHJlYWwsIEknbGwgcHJvYmFibHkNCj4gcHVudCB0byBRRU1VLiAgQnV0IEkgZWl0
aGVyIGhhdmUgdG8gYWRkIFN1bk9TIHN5c3RlbSBjYWxsDQo+IGVtdWxhdGlvbiB0byBRRU1VLCBv
ciBydW4gdGhlIHdob2xlIE9TIHVuZGVyIGhhcmR3YXJlIGVtdWxhdGlvbi4pDQo+IA0KPiBBbnl3
YXksIG1vc3Qgb2YgaXRzIGZpbGVzIGFyZSBhY3R1YWxseSBvbiBhIExpbnV4IE5GUyBzZXJ2ZXIN
Cj4gd2l0aCBhIHByb3BlciBSQUlEIGFuZCBiYWNrdXAgc3lzdGVtLg0KPiANCj4gSSdkIGtpbmQg
b2YgbGlrZSB0byBrZWVwIE5GU3YyIHdvcmtpbmcsIGlmIHlvdSBkb24ndCBtaW5kLg0KPiANCj4g
KCJJIGRvIG1pbmQ7IGluc3RhbGwgdW5mc2QiIGlzIHBlcmhhcHMgYSBsZWdpdGltYXRlIHJlc3Bv
bnNlLikNCg0KSSBkbyBtaW5kOyBpdCBpcyBjbGVhcmx5IHN0YXJ0aW5nIHRvIGJpdHJvdCBkdWUg
dG8gYW4gYWJzZW5jZSBvZiB1c2Vycy4NCk1haW50ZW5hbmNlIG9mIHVudXNlZCBjb2RlIGlzIGFj
dHVhbGx5IF9tb3JlXyBvZiBhIHBhaW4sIG5vdCBsZXNzLg0KDQpTbyB1bmZzZCBpcyBvbmUgc29s
dXRpb24uIEtlZXBpbmcgYSBWTSB3aXRoIGFuIG9sZGVyIHZlcnNpb24gb2YgdGhlDQpMaW51eCBr
ZXJuZWwgdGhhdCBzdGlsbCBzdXBwb3J0cyBORlN2MiBpcyBhbm90aGVyLiBWb2x1bnRlZXJpbmcg
dG8NCm1haW50YWluIHRoZSBjb2RlIGlzIGEgdGhpcmQuDQoNCi0tIA0KVHJvbmQgTXlrbGVidXN0
DQpMaW51eCBORlMgY2xpZW50IG1haW50YWluZXINCg0KTmV0QXBwDQpUcm9uZC5NeWtsZWJ1c3RA
bmV0YXBwLmNvbQ0Kd3d3Lm5ldGFwcC5jb20NCg==
On Mon, Oct 15, 2012 at 09:48:24PM -0400, George Spelvin wrote:
> It's NFSv2 server support that I, and I believe Larry, are interested
> in preserving, in order to provide services to ancient clients.
Yup. Exactly right.
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
On Mon, Oct 15, 2012 at 5:19 AM, Myklebust, Trond
<[email protected]> wrote:
> 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.
Growing pains can be hard for those who can't/won't update but when
it's time to move on, it's time to move on. Maintaining code _is_ in
fact a chore that eventually becomes counter-productive once the user
base has diminished enough and/or it's become so outdated. Your
suggestions might not thrill other people but then who likes taking
their medicine?
Cheers
T24gTW9uLCAyMDEyLTEwLTE1IGF0IDIxOjQ4IC0wNDAwLCBHZW9yZ2UgU3BlbHZpbiB3cm90ZToN
Cj4gVHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20gd3JvdGU6DQo+ID4gU1NCa2J5QnRhVzVrT3lC
cGRDQnBjeUJqYkdWaGNteDVJSE4wWVhKMGFXNW5JSFJ2SUdKcGRISnZkQ0JrZFdVZw0KPiA+IGRH
OGdZVzRnWVdKelpXNWpaU0J2WmlCMWMyVnljeTROQ2sxaGFXNTBaVzVoYm1ObElHOW1JSFZ1ZFhO
bFpDQmpiMlJsSUdseklHRmoNCj4gPiBkSFZoYkd4NUlGOXRiM0psWHlCdlppQmhJSEJoYVc0c0lH
NXZkQ0JzWlhOekxnMEtEUXBUYnlCMWJtWnpaQ0JwY3lCdmJtVWdjMjlzDQo+ID4gZFhScGIyNHVJ
RXRsWlhCcGJtY2dZU0JXVFNCM2FYUm9JR0Z1SUc5c1pHVnlJSFpsY25OcGIyNGdiMllnZEdobERR
cE1hVzUxZUNCcg0KPiA+IFpYSnVaV3dnZEdoaGRDQnpkR2xzYkNCemRYQndiM0owY3lCT1JsTjJN
aUJwY3lCaGJtOTBhR1Z5TGlCV2IyeDFiblJsWlhKcGJtY2cNCj4gPiBkRzhOQ20xaGFXNTBZV2x1
SUhSb1pTQmpiMlJsSUdseklHRWdkR2hwY21RdURRb04NCj4gDQo+IFdoaWNoIGNhbiBiZSBiYXNl
NjQgZGVjb2RlZCAod2h5IHdhcyBpdCBldmVyIEVOY29kZWQ/KSB0bw0KPiANCj4gPiBJIGRvIG1p
bmQ7IGl0IGlzIGNsZWFybHkgc3RhcnRpbmcgdG8gYml0cm90IGR1ZSB0byBhbiBhYnNlbmNlIG9m
IHVzZXJzLg0KPiA+IE1haW50ZW5hbmNlIG9mIHVudXNlZCBjb2RlIGlzIGFjdHVhbGx5IF9tb3Jl
XyBvZiBhIHBhaW4sIG5vdCBsZXNzLg0KPiA+DQo+ID4gU28gdW5mc2QgaXMgb25lIHNvbHV0aW9u
LiBLZWVwaW5nIGEgVk0gd2l0aCBhbiBvbGRlciB2ZXJzaW9uIG9mIHRoZQ0KPiA+IExpbnV4IGtl
cm5lbCB0aGF0IHN0aWxsIHN1cHBvcnRzIE5GU3YyIGlzIGFub3RoZXIuIFZvbHVudGVlcmluZyB0
bw0KPiA+IG1haW50YWluIHRoZSBjb2RlIGlzIGEgdGhpcmQuDQo+IA0KPiBJZiBJIG1pZ2h0IGFz
aywgdGhvdWdoLCBpcyB0aGUgcGFpbiBjb25jZW50cmF0ZWQgbW9yZSBvbiB0aGUgY2xpZW50IG9y
DQo+IHRoZSBzZXJ2ZXIgc2lkZT8NCj4gDQo+IE5GU3YyIHNlcnZlciBzdXBwb3J0IHNlZW1zIGEg
ZmFpcmx5IHNpbXBsZSBtYXR0ZXIgb2Ygc29tZSBvbGQNCj4gY29tcGF0aWJpbGl0eSBSUEMgY2Fs
bHMuICBUaGUgbWFpbiBwYWluIGlzIHRoZSBsaW1pdGVkIHNpemUgb2YgdGhlIGZpbGUNCj4gaGFu
ZGxlIGFuZCAoZXNwZWNpYWxseSkgcmVhZGRpciBjb29raWVzLg0KDQpXZWxsLCBJJ20gcmVhbGx5
IGdsYWQgdG8gaGVhciB0aGF0IGFmdGVyIHNldmVyYWwgcGVvcGxlIHNwZW50IDMtNCBob3Vycw0K
ZGVidWdnaW5nIGFuIE5GU3YyLW9ubHkgc2VydmVyIHNpZGUgcHJvYmxlbSBsYXN0IEZyaWRheS4g
UGxlYXNlIGxldCBtZQ0Ka25vdyB0aGUgbmV4dCB0aW1lIEkgY2FuIGhlbHAgZGVhbCB3aXRoIGFu
b3RoZXIgZmFpcmx5IHNpbXBsZSBtYXR0ZXIgb2YNCm9sZCBjb21wYXRpYmlsaXR5IGNhbGxzLi4u
DQoNCk9LLCBJJ2xsIGJpdGUuIFdoYXQgaXMgdGhpcyBidXNpbmVzcy1jcml0aWNhbCBhcHBsaWNh
dGlvbiB0aGF0IHlvdSBhcmUNCnJ1bm5pbmcgYW5kIHRoYXQgd2lsbCBvbmx5IHJ1biBvbiBhIG1h
Y2hpbmUgdGhhdCBpcyBpbmNhcGFibGUgb2YgcnVubmluZw0KYSBtZXJlIDIwLXllYXIgb2xkIHBy
b3RvY29sIGFuZCB0aGF0IG11c3QgaGF2ZSBhIDMwIHllYXIgb2xkIHByb3RvY29sPw0KVGhlIGZh
Y3QgdGhhdCB5b3UgYXJlIGFsbCBpbiBhIGh1ZmYgYWJvdXQgYmFzZTY0IGVuY29kZWQgZW1haWxz
DQppbmRpY2F0ZXMgdGhhdCB0aGlzIGlzIG5vdCBzb21ldGhpbmcgeW91IGFyZSBydW5uaW5nIG9u
IGFueXRoaW5nIGFzDQpzb3BoaXN0aWNhdGVkIGFzIGEgY2VsbCBwaG9uZS4NCg0KPiBDbGllbnQg
c3VwcG9ydCBpcyBwcm9iYWJseSBtb3JlIGNvbXBsaWNhdGVkLCBhcyBORlMncyAic3RhdGVsZXNz
IHNlcnZlciINCj4gbW9kZWwgcHV0cyB0aGUgYnVsayBvZiB0aGUgY29tcGxleGl0eSBvbiB0aGUg
Y2xpZW50LCBhbmQgeW91IG5lZWQgYQ0KPiB0aGlja2VyIGxheWVyIG9mIGxvZ2ljIHRvIHRyYW5z
bGF0ZSB0aGUgb3BlcmF0aW9ucyBpbnRvIGEgZGlmZmVyZW50DQo+IHZvY2FidWxhcnkgcGYgUlBD
IGNhbGxzLg0KPiANCj4gSSBkb24ndCB0aGluayBORlN2MiBjbGllbnQgc3VwcG9ydCB3b3VsZCBi
ZSBtb3VybmVkIG11Y2g7IHRyeWluZyB0byB0bw0KPiB1c2Ugc3VjaCBhbiBhbmNpZW50IGxpbWl0
ZWQgbWFjaGluZSBhcyBhIGZpbGUgc2VydmVyIHNlZW1zIHN0dXBpZC4NCj4gDQo+IEl0J3MgTkZT
djIgc2VydmVyIHN1cHBvcnQgdGhhdCBJLCBhbmQgSSBiZWxpZXZlIExhcnJ5LCBhcmUgaW50ZXJl
c3RlZA0KPiBpbiBwcmVzZXJ2aW5nLCBpbiBvcmRlciB0byBwcm92aWRlIHNlcnZpY2VzIHRvIGFu
Y2llbnQgY2xpZW50cy4NCj4gDQo+IFRoZSBvbmx5IHJlYWwgdXNlIG9mIHYyIGNsaWVudCBjb2Rl
IGlzIHRlIHRlc3QgdGhlIHNlcnZlci4NCg0KR29vZC4gVGhlbiBpdCB3b24ndCBiZSBtaXNzZWQu
DQoNCi0tIA0KVHJvbmQgTXlrbGVidXN0DQpMaW51eCBORlMgY2xpZW50IG1haW50YWluZXINCg0K
TmV0QXBwDQpUcm9uZC5NeWtsZWJ1c3RAbmV0YXBwLmNvbQ0Kd3d3Lm5ldGFwcC5jb20NCg==
Myklebust, Trond wrote:
The fact that you are all in a huff about base64 encoded emails
indicates that this is not something you are running on anything as
sophisticated as a cell phone.
The problem with your base64 email is that the vger server doesn't handle
them correctly.
[email protected] 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.
> Well, I'm really glad to hear that after several people spent 3-4 hours
> debugging an NFSv2-only server side problem last Friday. Please let me
> know the next time I can help deal with another fairly simple matter of
> old compatibility calls...
I didn't mean to rouse the sarcasm monster; I was, at your prompting,
investigating the effort of maintaining it myself.
Your .sig says "NFS client", I didn't see your name a lot in the fs/nfsd
directory changelogs, and I wondered, so I *asked*.
> OK, I'll bite. What is this business-critical application that you are
> running and that will only run on a machine that is incapable of running
> a mere 20-year old protocol and that must have a 30 year old protocol?
It's the firmware for an old embedded product, which I still do occasional
fixes for. The compiler it's been developed with is a binary from
a company that's long out of business, so I'm stuck running the old
binary on the old OS. (The product itself doesn't date back to 1990,
but the source code archives do, since the same platform was used for
earlier products.)
Yes, I *could* just port the whole thing over to GCC, but like most
embedded code, it's very sensitive to the environment, probably makes
some non-ANSI assumptions that will anger GCC's optimizer, *does* use
a different calling convention that will require fixing all the
assembly routines, and it would require a LOT of re-testing.
Since what we have now has decades of testing, and I'd rather spend my
time developing new products, keeping everything limping along has a
lot of advantages.
My most recent changes were in February 2011: an unusual combination
of commands could cause a lockup. Before that was adding a new baud
rate a customer needed in July 2010. There is very little effort,
but maintaining the capability is important.
I actually tried to compile git on SunOS, but things Didn't Work Well,
so what I do is do source control on the Linux NFS server, and just
use the old machine for the actual compiles.
> The fact that you are all in a huff about base64 encoded emails
> indicates that this is not something you are running on anything as
> sophisticated as a cell phone.
I didn't mean to come across as *that* peeved about the base64; it's
mostly annoying because I can't grep my mailbox, and my preferred
mailing list archive web interface (marc.info) doesn't decode them.
And it seems perverse for an MUA to encode something as base-64 that is
100% 7-bit ASCII. If nothing else, it bloats the message size 35%.