<html><head><style data-externalstyle="true"><!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst, p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle, p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
--></style></head><body><div data-externalstyle="false" dir="ltr" style="font-family:Calibri,'Segoe UI',Meiryo,'Microsoft YaHei UI','Microsoft JhengHei UI','Malgun Gothic','Khmer UI','Nirmala UI',Tunga,'Lao UI',Ebrima,sans-serif;font-size:12pt;"><div>All,</div><div> </div><div> A quick update. Looks like I was wrong about accidental deletion as we had another event when “tgt-admin --dump” was run. Looks like the tgtd daemon actually went 100% on the CPU it was on and was unresponsive to clients. Once the tgt-admin command was killed CPU usage returned to normal and clients where able to reconnect. Any ideas? Is this maybe a known bug in the version we are using? Thanks for any help. </div><div data-signatureblock="true"><div> </div><div>--<br>John P. Mitchell<br>jpmitchell@alaska.edu<br>Systems Administrator/Programmer<br>Elmer E. Rasmuson Library<br>907.474.1128</div><div> </div></div><div style="padding-top: 5px; border-top-color: rgb(229, 229, 229); border-top-width: 1px; border-top-style: solid;"><div><font face="Calibri, 'Segoe UI', Meiryo, 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', 'Khmer UI', 'Nirmala UI', Tunga, 'Lao UI', Ebrima, sans-serif" style='line-height: 15pt; letter-spacing: 0.02em; font-family: Calibri, "Segoe UI", Meiryo, "Microsoft YaHei UI", "Microsoft JhengHei UI", "Malgun Gothic", "Khmer UI", "Nirmala UI", Tunga, "Lao UI", Ebrima, sans-serif; font-size: 11pt;'><b>From:</b> John P. Mitchell<br><b>Sent:</b> Tuesday, October 15, 2013 11:06 AM<br><b>To:</b> stgt@lists.wpkg.org</font></div></div><div> </div>All,<br><br> I was attempting to dump out the running configuration of the tgtd daemon the other day. I ran the command "tgt-admin -dump" instead of "tgt-admin --dump". Sadly I was multi-tasking at the time and looked away for a few moments only to look back and wonder why the command was taking so long. Well, long story short all of my targets on that host ended up being deleted. Fortunately the targets where only one side of a mirrored array and operations where not heavily impacted. I am using version 1.0.24 of tgt packaged by Red Hat from their RHEL 6 distro. I looked at the git tree and it does not look like it should do this in either the version I am running or the version that is current. I am wondering if this is a parameter parsing bug or if I should request a feature to prompt when deleting targets to protect from fat fingered moments. I do have a feature request in that the built-in help in the command does not mention "-d" as a valid argument which led me to be bewildered for a while until I looked at the man page for a bit. So it seems the introduction in the man page and the built-in help could use a bit more detail. I am happy to provide diffs for updating the man page and the help in the tgt-admin perl script if that would be welcome. I am not real familiar with the Getopt Perl library so I am not sure what I can do to help but I am willing to try. If I have some time I will spin up a VM and try to replicate my problem with the 1.0.24 version and the current version from git. Thanks!<br><br>--<br>John P. Mitchell<br>jpmitchell@alaska.edu<br>Systems Administrator/Programmer<br>Elmer E. Rasmuson Library<br>907.474.1128<br><br><br><br><br><br></div></body></html>