svn commit: r316938 - head/sbin/savecore

[Rodney W. Grimes]

> > On 4/14/17, 8:35 PM, "Rodney W. Grimes" <freebsd at pdx.rh.CN85.dnsmgr.net> wrote:
> > 
> > > Yeah, I have the following:
> >     > borg.lerctr.org /home/ler $ swapctl -l
> >     > Device:       1024-blocks     Used:
> >     > /dev/mfid0p3    8388608         0
> >     > /dev/mfid1p3    8388608         0
> >     > /dev/mfid2p3    8388608         0
> >     > /dev/mfid3p3    8388608         0
> >     > /dev/mfid4p3    8388608         0
> >     > /dev/mfid5p3    8388608         0
> >     > borg.lerctr.org /home/ler $ sysctl hw.physmem
> >     > hw.physmem: 137368682496
> >     > borg.lerctr.org /home/ler $
> >     > 
> >     > SO 6 8G partitions (48G), but the dump is larger than 8G. 
> >     
> >     Larry,
> >       This is a very good concern and point given todays more
> >     common huge memory foot prints and lots of spindles.  I'll
> >     keep this in they back of my mind as I tromp around in the
> >     dump code.  I have another solution that may work for you
> >     and that is to use Netdump rather than swapdump.  This
> >     basically eliminates the trip to swap space and you end
> >     up going to savecore style output on the netdump server.
> >     
> >     -- 
> >     Rod Grimes                                                 rgrimes at freebsd.org
> >     
> > What does it take for NetDump to work to a FreeNAS (9.10 nightly) server since that?s what is ?next to? this server?  
> 
> As a netdump server FreeNAS would be fairly trivial to compile the netdump
> client code for.    I should have running 11.0 and 10.2 code around
> some place.

You know, maybe we should get the client side code pushed in, that
has been stable and not stomped on by other changes and is usable
for those of us who have kernels that can do netdump. 

It is a fairly simple daemon that listens on a socket and stores
the dumps.

-- 
Rod Grimes                                                 rgrimes at freebsd.org