> netstat output doesn't show any significant differences and seems not
quoted text
> depending on kern.openfiles

Then I have no idea what might be incrementing "openfiles" inside the
nfs server.

quoted text
> I did "ls -l /usr/src/UPDATING" and "ls -l /usr/src/README" on freebsd
> and dfbsd clients
> Doing tcpdump on clients shows two differences:
> - DF flag missing on dfbsd (seems irrelevant here)
> - using "fsinfo" on dfbsd client and "access" on freebsd client
> 
> 
> from freebsd client:
> 
> 19:26:10.001804 IP (tos 0x0, ttl  64, id 55387, offset 0, flags [DF],
> proto: TCP (6), length: 156) 10.59.3.10.48901580 > 10.59.3.38.2049: 104
> access fh 1137,915245/31068487 003f
> 19:26:10.002255 IP (tos 0x0, ttl  64, id 5316, offset 0, flags [DF],
> proto: TCP (6), length: 176) 10.59.3.38.2049 > 10.59.3.10.48901580:
> reply ok 124 access attr: DIR 755 ids 1085/1085 sz 512 c 0023
> 19:26:10.002571 IP (tos 0x0, ttl  64, id 55388, offset 0, flags [DF],
> proto: TCP (6), length: 164) 10.59.3.10.48901581 > 10.59.3.38.2049: 112
> lookup fh 1137,915245/31068487 "README"
> 19:26:10.003035 IP (tos 0x0, ttl  64, id 5317, offset 0, flags [DF],
> proto: TCP (6), length: 292) 10.59.3.38.2049 > 10.59.3.10.48901581:
> reply ok 240 lookup fh 1137,915245/31069628 REG 644 ids 1085/1085 sz
> 2816
> 19:26:10.102454 IP (tos 0x0, ttl  64, id 55391, offset 0, flags [DF],
> proto: TCP (6), length: 52) 10.59.3.10.726 > 10.59.3.38.2049: ., cksum
> 0xfa26 (correct), ack 2727185215 win 65535 <nop,nop,timestamp 2748662478
> 1135145875>
> 
> 
> from dfbsd client:
> 
> 19:28:16.612420 IP (tos 0x0, ttl  64, id 21333, offset 0, flags [none],
> proto: TCP (6), length: 148) 10.59.19.2.1451380236 > 10.59.3.38.2049: 96
> fsinfo fh 1137,915245/31349706
> 19:28:16.615021 IP (tos 0x0, ttl  59, id 17993, offset 0, flags [DF],
> proto: TCP (6), length: 220) 10.59.3.38.2049 > 10.59.19.2.1451380236:
> reply ok 168 fsinfo POST: DIR 755 ids 1085/1085 sz 512 rtmax 32768
> rtpref 32768 wtmax 32768 wtpref 32768 dtpref 32768 rtmult 512 wtmult 512
> maxfsz 4398046511103 delta 0.000001
> 19:28:16.615203 IP (tos 0x0, ttl  64, id 30045, offset 0, flags [none],
> proto: TCP (6), length: 168) 10.59.19.2.1451380237 > 10.59.3.38.2049:
> 116 lookup fh 1137,915245/31349706 "UPDATING"
> 19:28:16.617353 IP (tos 0x0, ttl  59, id 17994, offset 0, flags [DF],
> proto: TCP (6), length: 292) 10.59.3.38.2049 > 10.59.19.2.1451380237:
> reply ok 240 lookup fh 1137,915245/31353680 REG 644 ids 0/1085 sz 9474
> 19:28:16.710894 IP (tos 0x0, ttl  64, id 64120, offset 0, flags [none],
> proto: TCP (6), length: 52) 10.59.19.2.800 > 10.59.3.38.2049: ., cksum
> 0x270b (correct), ack 409 win 65535 <nop,nop,timestamp 33949536
> 1135272468>
> 
> 
> 10.59.3.10 - freebsd client
> 10.59.19.2 - dfbsd client
> 10.59.3.38 - freebsd nfs server
> 
> At first glance seems that freebsd has some problems with "fsinfo", I'll
> try to dig deeper later
 
From the above, I don't see any problems. The fsinfo on the wire looks ok to me.
(It just gives overall info on the server's file system to the client and
 the reply looks ok. It might be that FreeBSD6.3's server code does
 something weird to get the info and does an falloc() or similar. Normally
 Fsinfo RPCs don't occur often, so a leak in it on the server might not be
 easily spotted?)
I also agree that I can't think of a reason why having or not having a
Don't Fragment flag on the IP Datagram, would have any effect.

Btw, although my name may still be on the files, I haven't had anything to do
with the code currently in FreeBSD for a very long time. If you find that
doing Fsinfo RPCs is causing the leak, I think it needs to filed as a bug
with FreeBSD.

rick