> Maybe you can use "showmount -a SERVER-IP", foreach server you have... > That might work. NFS doesn't actually have a notion of a "mount", but the mount protocol daemon (typically called mountd) does try and keep track of NFSv3 mounts from the requests it sees. How well this works for NFSv3 will depend on how well the server keeps track of these things and how easily they are lost during a server reboot or similar.
Since NFSv4 doesn't use the mount protocol, it will be useless for NFSv4. > Thiago > 2011/5/30 Mark Saad <nones...@longcount.org>: > > On Mon, May 30, 2011 at 8:13 PM, Rick Macklem <rmack...@uoguelph.ca> > > wrote: > >>> Hello All > >>> So I am stumped on this one. I want to know what the IP of each > >>> nfs server that is providing each nfs export. I am running > >>> 7.4-RELEASE > >>> When I run "mount -t nfs" I see something like this > >>> > >>> VIP-01:/export/source on /mnt/src > >>> VIP-02:/export/target on /mnt/target > >>> VIP-01:/export/logs on /mnt/logs > >>> VIP-02:/export/package on /mnt/pkg > >>> > >>> The issue is I use a load balanced nfs server , from isilon. So > >>> VIP-01 > >>> could be any one of a group of IPs . I am trying to track down a > >>> network congestion issue and I cant find a way to match the output > >>> of > >>> lsof , and netstat to the output of mount -t nfs . Does anyone > >>> have > >>> any ideas how I could track this down , is there a way to run > >>> mount > >>> and have it show the IP and not the name of the source server ? > >>> > >> Just fire up wireshark (or tcpdump) and watch the traffic. tcpdump > >> doesn't know much about NFS, but if al you want are the IP#s, it'll > >> do. > >> > >> But, no, mount won't tell you more than what the argument looked > >> like. > >> > >> rick > >> > > Wireshark seams like using a tank to swap a fly. > > Maybe, but watching traffic isn't that scary and over the years I've discovered things I would have never expected from doing it. Like a case where one specific TCP segment was being dropped by a network switch (it was a hardware problem in the switch that didn't manifest itself any other way). Or, that one client was generating a massive number of Getattr and Lookup RPCs. (That one turned out to be a grad student who had made themselves an app. that had a bunch of threads continually scanning to fs changes. Not a bad idea, but the threads never took a break and continually did it.) I've always found watching traffic kinda fun, but then I'm weird, rick _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
