On Sat, 28 Jan 2012 01:16:41 +0900 FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote: > On Fri, 27 Jan 2012 16:12:20 +1100 > ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote: > > > From 17fdaf426120d6167b7f14068d7c6f4ca0322217 Mon Sep 17 00:00:00 2001 > > From: Ronnie Sahlberg <ronniesahlberg@xxxxxxxxx> > > Date: Fri, 27 Jan 2012 16:07:00 +1100 > > Subject: [PATCH] Add PREVENT/ALLOW MEDIUM REMOVAL and START STOP UNIT > > > > Implement logic for PAMR and SSU. > > > > Add a new attribute .prevent to track the allow prevent removal status of a LUN. > > Implement PAMR and update the LUN attribute accordingly. > > > > Units where PAMR is set to prevent removal of the device can not be > > made offline using tgtadm. Attempts to make the unit offline > > will fail with a new TGTADM error to indicate there is a PAMR lock on the device. > > > > SSU attempts to "eject" the media will fail with a check condition > > if the media is locked by PAMR. > > > > If SSU successfully "ejects" the media, we automatically set the LUN to "Offline". > > > > Update tgt_target_show_all() to show the PreventRemoval status for the LUN in the output. > > > > Signed-off-by: Ronnie Sahlberg <ronniesahlberg@xxxxxxxxx> > > --- > > doc/tgtadm.8.xml | 47 +++++++++++++++++++++++++++++++++++++++++++++++ > > usr/mmc.c | 10 ++-------- > > usr/sbc.c | 2 +- > > usr/spc.c | 43 ++++++++++++++++++++++++++++++++++++------- > > usr/target.c | 15 +++++++++++++-- > > usr/tgtadm.c | 4 +++- > > usr/tgtadm_error.h | 2 ++ > > usr/tgtd.h | 5 +++++ > > 8 files changed, 109 insertions(+), 19 deletions(-) > > Thanks a lot! Another "TODO: implement properly" comment removal! > > SPC3 says: > > The prevention of medium removal shall begin when any application > client issues a PREVENT ALLOW MEDIUM REMOVAL command with a PREVENT > field of 01b or 11b (i.e., medium removal prevented). The prevention > of medium removal for the logical unit shall terminate after: > > a) One of the following occurs for each I_T nexus that previously had > medium removal prevented: > A) Receipt of a PREVENT ALLOW MEDIUM REMOVAL command with a PREVENT > field of 00b or 10b; > B) An I_T nexus loss; or > > With the current code, even an I_T nexus that previously had NOT > medium removal prevented can terminate the prevention of medium > removal? Is that against the spec, No? And of course, we need to terminate the prevention of medium removal when the I_T nexus that previously had medium removal prevented loses. So I guess that we need some data structures per nexus for this feature. -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html