Peter Memishian wrote:
> > Currently I want do some core dump on network device. but I don't
> > know how to do that. As we know that during system dump, all thread
> > freezed instead of specified file system's dump thread. system become
> > single thread at this time. but seems TCP/IP stack is multi-thread
> > program, if we want to dump core file to network storage through
> > TCP/IP stack, how could we do that?
> >
> > I had checked nfs_dump() in opensolaris source code, it use KTLI API
> > function to dump nfs file through UDP protocol, but can we use TCP
> > KTLI API here instead? or can here we start kernel TCP socket to
> > transfer core dump file here?
>
> While we've had support for dumping over NFS in the past (using polling
> rather than interrupts), I'm not sure how well it actually works.
> Further, even if it does work, I'd argue it's at odds with the core
> constraints associated with panicking the system, which is that the panic
> operation should be as safe and reliable as possible. That is, since the
> system is already known to be irrecoverably damaged at panic time, it
> seems dangerous to rely on the correct operation of large subsystems such
> as the networking stack to write out the dump -- and one may compromise
> the integrity of the dump (or worse) by doing so.
>
>
So I suppose the question is, how does one properly get a system dump
from a system that is using exclusively something like iSCSI?
I have no idea what the answer is.
I *strongly* doubt, however, that all of the NIC drivers will operate
properly without interrupts. I suppose one could periodically poll
their ISRs, to simulate an interrupt, but I am not aware that stack does
this.
By the way, the same problem exists for USB. I am pretty sure that the
usb mass storage (and also 1394 mass storage) drivers explicitly do not
support dump(9e).
It may be that the end game of this is, if you want to capture system
crash dumps, then you should attach a local SCSI or IDE HBA drive. I'm
not sure any such advice has ever been given formally, but maybe it
should be.
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
