> netstat output doesn't show any significant differences and seems not > depending on kern.openfiles
Then I have no idea what might be incrementing "openfiles" inside the nfs server. > 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
