Re: IMPORTANT....initiator sensing target daemonrestart
|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
 |
Re: IMPORTANT....initiator sensing target daemonrestart
by rswwalker
::
Rate this Message:
You don't need to restart the target daemon, use ietadm to add/remove targets and luns while the daemon is running. This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Iscsitarget-devel mailing list Iscsitarget-devel@... https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel |
|
|
Re: IMPORTANT....initiator sensing target daemonrestart
by Jeff Waller
::
Rate this Message:
On Jul 2, 2008, at 9:21 AM, Ross S. W. Walker wrote:
BTW my mods are coming along, I should have an update on this by this weekend. There appear to be some serious issues to the current implementation. But, what's this about having to drop packets? Can you point to a previous discussion here?
I think his intention is that he should not have to poll, but this new information should be announced. Or maybe he doesn't care, but having read this, I think I do. What does the protocol have for us in this area?
------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Iscsitarget-devel mailing list Iscsitarget-devel@... https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel |
|
|
Re: IMPORTANT....initiator sensing target daemonrestart
by Ming Zhang-3
::
Rate this Message:
On Wed, 2008-07-02 at 10:21 -0400, Jeff Waller wrote:
> > On Jul 2, 2008, at 9:21 AM, Ross S. W. Walker wrote: > > > > > You don't need to restart the target daemon, use ietadm to > > add/remove targets and luns while the daemon is running. > > > > > > If at some point you do need to restart the target for some reason, > > make sure to use iptables to drop port unreachable packets, either > > always, or right before restart and disable right after. > > > > > BTW my mods are coming along, I should have an update on this by this > weekend. There appear > to be some serious issues to the current implementation. But, what's > this about having to drop packets? > Can you point to a previous discussion here? search list archive about iptable to help ietd restart. > > After adding target or lun, then do a session rescan and it will > > find the new targets/luns. > > > > > I think his intention is that he should not have to poll, but this new > information should be > announced. Or maybe he doesn't care, but having read this, I think I > do. > > > What does the protocol have for us in this area? as Ross pointed out, use ietadm to add LU without restarting the ietd. but current implementation lack the ability to notify ini side regarding the new LU, u still have to rescan the session at ini side. SCSI protocol covers this with: after target have a new LU, target send back a sense with REPORT_LUNS information changed Unit attention. this will let ini to reissue the report_luns command. but (1) iet does not have this. (2) not sure if linux scsi layer at ini side support this. why not simply add a LU to another target? > > > -Jeff > > > > > > -Ross > > > > > > ----- Original Message ----- > > From: iscsitarget-devel-bounces@... > > <iscsitarget-devel-bounces@...> > > To: iscsitarget-devel@... > > <iscsitarget-devel@...> > > Sent: Wed Jul 02 05:38:28 2008 > > Subject: [Iscsitarget-devel] IMPORTANT....initiator sensing target > > daemonrestart > > > > Hello, > > > > Consider the scenario, > > > > "Open-iSCSI" initiator connected to one "IET" target from target > > machine. > > > > Presently 2 LUN's were attached to it. > > > > Target machine adds 3rd LUN to the same target which is exposed to > > increase storage. > > > > "Target machine daemon(iscsi-target)" is restarted to make the > > changes reflect the initiator side. > > > > Initiator may/may not be undergoing I/O on the 2 exposed LUN's at > > that instance. > > > > on firing "iscsiadm -m session -P 3",it will show status as > > "Blocked" for 1-2 seconds indicating that target configuration is > > changed. > > > > Then initiator has to perform "iscsiadm -m session --rescan" to add > > the 3rd LUN to target already exposed. > > > > My question is, > > > > 1. Which signal target sends to initiator so that it can know target > > daemon is restarted?? > > > > I want initiator to have access of 3rd LUN after target added > > it.i.e. on which event,I should run "iscsiadm -m session > > --rescan"?? > > > > 2. One way could be on initiator side,I should write a > > daemon/program to run "iscsiadm -m session -P 3" continuously to > > sense if Disk > > > > state is "blocked" and iSCSI state is "REOPEN".At that instance, > > I can run "iscsiadm -m session --rescan" to make changes reflect. > > > > > > > > > > > > > > > > > > ____________________________________________________________________ > > This e-mail, and any attachments thereto, is intended only for use > > by the addressee(s) named herein and may contain legally privileged > > and/or confidential information. If you are not the intended > > recipient of this e-mail, you are hereby notified that any > > dissemination, distribution or copying of this e-mail, and any > > attachments thereto, is strictly prohibited. If you have received > > this e-mail in error, please immediately notify the sender and > > permanently delete the original and any copy or printout thereof. > > ------------------------------------------------------------------------- > > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > > Studies have shown that voting for your favorite open source > > project, > > along with a healthy diet, reduces your potential for chronic > > lameness > > and boredom. Vote Now at > > http://www.sourceforge.net/community/cca08_______________________________________________ > > Iscsitarget-devel mailing list > > Iscsitarget-devel@... > > https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ Iscsitarget-devel mailing list Iscsitarget-devel@... https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel Ming Zhang @#$%^ purging memory... (*!% http://blackmagic02881.wordpress.com/ http://www.linkedin.com/in/blackmagic02881 -------------------------------------------- ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Iscsitarget-devel mailing list Iscsitarget-devel@... https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel |
|
|
Re: IMPORTANT....initiator sensing target daemonrestart
by Jeff Waller
::
Rate this Message:
On Jul 2, 2008, at 10:33 AM, Ming Zhang wrote: > On Wed, 2008-07-02 at 10:21 -0400, Jeff Waller wrote: >> >> On Jul 2, 2008, at 9:21 AM, Ross S. W. Walker wrote: >> >>> >>> You don't need to restart the target daemon, use ietadm to >>> add/remove targets and luns while the daemon is running. >>> >>> >>> If at some point you do need to restart the target for some reason, >>> make sure to use iptables to drop port unreachable packets, either >>> always, or right before restart and disable right after. >>> >>> >> BTW my mods are coming along, I should have an update on this by this >> weekend. There appear >> to be some serious issues to the current implementation. But, what's >> this about having to drop packets? >> Can you point to a previous discussion here? > > > search list archive about iptable to help ietd restart. Will do thanks Ming, I might have some followup questions later after having read the thread. > > > >>> After adding target or lun, then do a session rescan and it will >>> find the new targets/luns. >>> >>> >> I think his intention is that he should not have to poll, but this >> new >> information should be >> announced. Or maybe he doesn't care, but having read this, I think I >> do. >> >> >> What does the protocol have for us in this area? > > as Ross pointed out, use ietadm to add LU without restarting the ietd. > but current implementation lack the ability to notify ini side > regarding > the new LU, u still have to rescan the session at ini side. > > SCSI protocol covers this with: after target have a new LU, target > send > back a sense with REPORT_LUNS information changed Unit attention. this > will let ini to reissue the report_luns command. Ok, good deal, the iSCSI protocol does have a mechanism for allowing the target to send change notifications. We simply have to implement it. > > > but (1) iet does not have this. (2) not sure if linux scsi layer at > ini > side support this. > > why not simply add a LU to another target? Administrative complication, maybe. > > > > >> >> >> -Jeff >>> >>> >>> -Ross >>> >>> >>> ----- Original Message ----- >>> From: iscsitarget-devel-bounces@... >>> <iscsitarget-devel-bounces@...> >>> To: iscsitarget-devel@... >>> <iscsitarget-devel@...> >>> Sent: Wed Jul 02 05:38:28 2008 >>> Subject: [Iscsitarget-devel] IMPORTANT....initiator sensing target >>> daemonrestart >>> >>> Hello, >>> >>> Consider the scenario, >>> >>> "Open-iSCSI" initiator connected to one "IET" target from target >>> machine. >>> >>> Presently 2 LUN's were attached to it. >>> >>> Target machine adds 3rd LUN to the same target which is exposed to >>> increase storage. >>> >>> "Target machine daemon(iscsi-target)" is restarted to make the >>> changes reflect the initiator side. >>> >>> Initiator may/may not be undergoing I/O on the 2 exposed LUN's at >>> that instance. >>> >>> on firing "iscsiadm -m session -P 3",it will show status as >>> "Blocked" for 1-2 seconds indicating that target configuration is >>> changed. >>> >>> Then initiator has to perform "iscsiadm -m session --rescan" to add >>> the 3rd LUN to target already exposed. >>> >>> My question is, >>> >>> 1. Which signal target sends to initiator so that it can know target >>> daemon is restarted?? >>> >>> I want initiator to have access of 3rd LUN after target added >>> it.i.e. on which event,I should run "iscsiadm -m session >>> --rescan"?? >>> >>> 2. One way could be on initiator side,I should write a >>> daemon/program to run "iscsiadm -m session -P 3" continuously to >>> sense if Disk >>> >>> state is "blocked" and iSCSI state is "REOPEN".At that instance, >>> I can run "iscsiadm -m session --rescan" to make changes reflect. >>> >>> >>> >>> >>> >>> >>> >>> >>> ____________________________________________________________________ >>> This e-mail, and any attachments thereto, is intended only for use >>> by the addressee(s) named herein and may contain legally privileged >>> and/or confidential information. If you are not the intended >>> recipient of this e-mail, you are hereby notified that any >>> dissemination, distribution or copying of this e-mail, and any >>> attachments thereto, is strictly prohibited. If you have received >>> this e-mail in error, please immediately notify the sender and >>> permanently delete the original and any copy or printout thereof. >>> ------------------------------------------------------------------------- >>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >>> Studies have shown that voting for your favorite open source >>> project, >>> along with a healthy diet, reduces your potential for chronic >>> lameness >>> and boredom. Vote Now at >>> http://www.sourceforge.net/community/cca08_______________________________________________ >>> Iscsitarget-devel mailing list >>> Iscsitarget-devel@... >>> https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel >> >> ------------------------------------------------------------------------- >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >> Studies have shown that voting for your favorite open source project, >> along with a healthy diet, reduces your potential for chronic >> lameness >> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >> _______________________________________________ Iscsitarget-devel >> mailing list Iscsitarget-devel@... https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel > -- > Ming Zhang > > > @#$%^ purging memory... (*!% > http://blackmagic02881.wordpress.com/ > http://www.linkedin.com/in/blackmagic02881 > -------------------------------------------- > ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Iscsitarget-devel mailing list Iscsitarget-devel@... https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel |
|
|
Re: IMPORTANT....initiator sensing target daemonrestart
by Ming Zhang-3
::
Rate this Message:
On Wed, 2008-07-02 at 10:54 -0400, Jeff Waller wrote:
> On Jul 2, 2008, at 10:33 AM, Ming Zhang wrote: > > > On Wed, 2008-07-02 at 10:21 -0400, Jeff Waller wrote: > >> > >> On Jul 2, 2008, at 9:21 AM, Ross S. W. Walker wrote: > >> > >>> > >>> You don't need to restart the target daemon, use ietadm to > >>> add/remove targets and luns while the daemon is running. > >>> > >>> > >>> If at some point you do need to restart the target for some reason, > >>> make sure to use iptables to drop port unreachable packets, either > >>> always, or right before restart and disable right after. > >>> > >>> > >> BTW my mods are coming along, I should have an update on this by this > >> weekend. There appear > >> to be some serious issues to the current implementation. But, what's > >> this about having to drop packets? > >> Can you point to a previous discussion here? > > > > > > search list archive about iptable to help ietd restart. > > Will do thanks Ming, I might have some followup questions later after > having read the thread. > sure. > > > > > > > >>> After adding target or lun, then do a session rescan and it will > >>> find the new targets/luns. > >>> > >>> > >> I think his intention is that he should not have to poll, but this > >> new > >> information should be > >> announced. Or maybe he doesn't care, but having read this, I think I > >> do. > >> > >> > >> What does the protocol have for us in this area? > > > > as Ross pointed out, use ietadm to add LU without restarting the ietd. > > but current implementation lack the ability to notify ini side > > regarding > > the new LU, u still have to rescan the session at ini side. > > > > SCSI protocol covers this with: after target have a new LU, target > > send > > back a sense with REPORT_LUNS information changed Unit attention. this > > will let ini to reissue the report_luns command. > > Ok, good deal, the iSCSI protocol does have a mechanism for allowing the > target to send change notifications. We simply have to implement it. sorry, but it is SCSI protocol, not iSCSI protocol... > > > > > > > but (1) iet does not have this. (2) not sure if linux scsi layer at > > ini > > side support this. > > > > why not simply add a LU to another target? > > Administrative complication, maybe. > one LU, one target, give to one ini. u will find it simpler in long run. especially when u have multiple ini and need access control... of course, my personal opinion... also one lu per target might be faster if you have fast storage (>200MB/s) and fast network (like 10Gbps), > > > > > > > > > >> > >> > >> -Jeff > >>> > >>> > >>> -Ross > >>> > >>> > >>> ----- Original Message ----- > >>> From: iscsitarget-devel-bounces@... > >>> <iscsitarget-devel-bounces@...> > >>> To: iscsitarget-devel@... > >>> <iscsitarget-devel@...> > >>> Sent: Wed Jul 02 05:38:28 2008 > >>> Subject: [Iscsitarget-devel] IMPORTANT....initiator sensing target > >>> daemonrestart > >>> > >>> Hello, > >>> > >>> Consider the scenario, > >>> > >>> "Open-iSCSI" initiator connected to one "IET" target from target > >>> machine. > >>> > >>> Presently 2 LUN's were attached to it. > >>> > >>> Target machine adds 3rd LUN to the same target which is exposed to > >>> increase storage. > >>> > >>> "Target machine daemon(iscsi-target)" is restarted to make the > >>> changes reflect the initiator side. > >>> > >>> Initiator may/may not be undergoing I/O on the 2 exposed LUN's at > >>> that instance. > >>> > >>> on firing "iscsiadm -m session -P 3",it will show status as > >>> "Blocked" for 1-2 seconds indicating that target configuration is > >>> changed. > >>> > >>> Then initiator has to perform "iscsiadm -m session --rescan" to add > >>> the 3rd LUN to target already exposed. > >>> > >>> My question is, > >>> > >>> 1. Which signal target sends to initiator so that it can know target > >>> daemon is restarted?? > >>> > >>> I want initiator to have access of 3rd LUN after target added > >>> it.i.e. on which event,I should run "iscsiadm -m session > >>> --rescan"?? > >>> > >>> 2. One way could be on initiator side,I should write a > >>> daemon/program to run "iscsiadm -m session -P 3" continuously to > >>> sense if Disk > >>> > >>> state is "blocked" and iSCSI state is "REOPEN".At that instance, > >>> I can run "iscsiadm -m session --rescan" to make changes reflect. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> ____________________________________________________________________ > >>> This e-mail, and any attachments thereto, is intended only for use > >>> by the addressee(s) named herein and may contain legally privileged > >>> and/or confidential information. If you are not the intended > >>> recipient of this e-mail, you are hereby notified that any > >>> dissemination, distribution or copying of this e-mail, and any > >>> attachments thereto, is strictly prohibited. If you have received > >>> this e-mail in error, please immediately notify the sender and > >>> permanently delete the original and any copy or printout thereof. > >>> ------------------------------------------------------------------------- > >>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > >>> Studies have shown that voting for your favorite open source > >>> project, > >>> along with a healthy diet, reduces your potential for chronic > >>> lameness > >>> and boredom. Vote Now at > >>> http://www.sourceforge.net/community/cca08_______________________________________________ > >>> Iscsitarget-devel mailing list > >>> Iscsitarget-devel@... > >>> https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel > >> > >> ------------------------------------------------------------------------- > >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > >> Studies have shown that voting for your favorite open source project, > >> along with a healthy diet, reduces your potential for chronic > >> lameness > >> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > >> _______________________________________________ Iscsitarget-devel > >> mailing list Iscsitarget-devel@... https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel > > -- > > Ming Zhang > > > > > > @#$%^ purging memory... (*!% > > http://blackmagic02881.wordpress.com/ > > http://www.linkedin.com/in/blackmagic02881 > > -------------------------------------------- > > > Ming Zhang @#$%^ purging memory... (*!% http://blackmagic02881.wordpress.com/ http://www.linkedin.com/in/blackmagic02881 -------------------------------------------- ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Iscsitarget-devel mailing list Iscsitarget-devel@... https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel |
|
|
Re: IMPORTANT....initiator sensing target daemonrestart
by Jeff Waller
::
Rate this Message:
On Jul 2, 2008, at 10:59 AM, Ming Zhang wrote: > On Wed, 2008-07-02 at 10:54 -0400, Jeff Waller wrote: >> On Jul 2, 2008, at 10:33 AM, Ming Zhang wrote: >> >>> On Wed, 2008-07-02 at 10:21 -0400, Jeff Waller wrote: >>>> >>>> On Jul 2, 2008, at 9:21 AM, Ross S. W. Walker wrote: >>>> >>>>> >>>>> You don't need to restart the target daemon, use ietadm to >>>>> add/remove targets and luns while the daemon is running. >>>>> >>>>> >>>>> If at some point you do need to restart the target for some >>>>> reason, >>>>> make sure to use iptables to drop port unreachable packets, either >>>>> always, or right before restart and disable right after. >>>>> >>>>> >>>> BTW my mods are coming along, I should have an update on this by >>>> this >>>> weekend. There appear >>>> to be some serious issues to the current implementation. But, >>>> what's >>>> this about having to drop packets? >>>> Can you point to a previous discussion here? >>> >>> >>> search list archive about iptable to help ietd restart. >> >> Will do thanks Ming, I might have some followup questions later >> after >> having read the thread. >> > > sure. Ok I read some threads, and this appears to be a workaround to a bug in ietd that it doesn't support reload other than stop-start (as of like last year) still true, I take it? The problem is that connection requests are responded to (connection refused) as opposed to dropped. iptables is a workaround for that. > > >>> >>> >>> >>>>> After adding target or lun, then do a session rescan and it will >>>>> find the new targets/luns. >>>>> >>>>> >>>> I think his intention is that he should not have to poll, but this >>>> new >>>> information should be >>>> announced. Or maybe he doesn't care, but having read this, I >>>> think I >>>> do. >>>> >>>> >>>> What does the protocol have for us in this area? >>> >>> as Ross pointed out, use ietadm to add LU without restarting the >>> ietd. >>> but current implementation lack the ability to notify ini side >>> regarding >>> the new LU, u still have to rescan the session at ini side. >>> >>> SCSI protocol covers this with: after target have a new LU, target >>> send >>> back a sense with REPORT_LUNS information changed Unit attention. >>> this >>> will let ini to reissue the report_luns command. >> >> Ok, good deal, the iSCSI protocol does have a mechanism for >> allowing the >> target to send change notifications. We simply have to implement it. > > sorry, but it is SCSI protocol, not iSCSI protocol... Got it. > > > >> >>> >>> >>> but (1) iet does not have this. (2) not sure if linux scsi layer at >>> ini >>> side support this. >>> >>> why not simply add a LU to another target? >> >> Administrative complication, maybe. >> > > one LU, one target, give to one ini. u will find it simpler in long > run. > especially when u have multiple ini and need access control... of > course, my personal opinion... But what if you want to make available a number of disks, and only what to specify the configuration information common to all of that once. Most of the configuration information is based on the target not the LUN, eh? Additionally, isn't it the target that you can specify a maximum number of connections (e.g. maximum 10 users per target) == maximum 10 users/pool of data. > > > also one lu per target might be faster if you have fast storage > (>200MB/s) and fast network (like 10Gbps), If in your experience, we don't need more than 1 LUN/Target, that begs the question then, why LUNs exist at all, is this a holdover from SCSI? > > > > >>> >>> >>> >>> >>>> >>>> >>>> -Jeff >>>>> >>>>> >>>>> -Ross >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: iscsitarget-devel-bounces@... >>>>> <iscsitarget-devel-bounces@...> >>>>> To: iscsitarget-devel@... >>>>> <iscsitarget-devel@...> >>>>> Sent: Wed Jul 02 05:38:28 2008 >>>>> Subject: [Iscsitarget-devel] IMPORTANT....initiator sensing target >>>>> daemonrestart >>>>> >>>>> Hello, >>>>> >>>>> Consider the scenario, >>>>> >>>>> "Open-iSCSI" initiator connected to one "IET" target from target >>>>> machine. >>>>> >>>>> Presently 2 LUN's were attached to it. >>>>> >>>>> Target machine adds 3rd LUN to the same target which is exposed to >>>>> increase storage. >>>>> >>>>> "Target machine daemon(iscsi-target)" is restarted to make the >>>>> changes reflect the initiator side. >>>>> >>>>> Initiator may/may not be undergoing I/O on the 2 exposed LUN's at >>>>> that instance. >>>>> >>>>> on firing "iscsiadm -m session -P 3",it will show status as >>>>> "Blocked" for 1-2 seconds indicating that target configuration is >>>>> changed. >>>>> >>>>> Then initiator has to perform "iscsiadm -m session --rescan" to >>>>> add >>>>> the 3rd LUN to target already exposed. >>>>> >>>>> My question is, >>>>> >>>>> 1. Which signal target sends to initiator so that it can know >>>>> target >>>>> daemon is restarted?? >>>>> >>>>> I want initiator to have access of 3rd LUN after target added >>>>> it.i.e. on which event,I should run "iscsiadm -m session >>>>> --rescan"?? >>>>> >>>>> 2. One way could be on initiator side,I should write a >>>>> daemon/program to run "iscsiadm -m session -P 3" continuously to >>>>> sense if Disk >>>>> >>>>> state is "blocked" and iSCSI state is "REOPEN".At that instance, >>>>> I can run "iscsiadm -m session --rescan" to make changes reflect. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ____________________________________________________________________ >>>>> This e-mail, and any attachments thereto, is intended only for use >>>>> by the addressee(s) named herein and may contain legally >>>>> privileged >>>>> and/or confidential information. If you are not the intended >>>>> recipient of this e-mail, you are hereby notified that any >>>>> dissemination, distribution or copying of this e-mail, and any >>>>> attachments thereto, is strictly prohibited. If you have received >>>>> this e-mail in error, please immediately notify the sender and >>>>> permanently delete the original and any copy or printout thereof. >>>>> ------------------------------------------------------------------------- >>>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >>>>> Studies have shown that voting for your favorite open source >>>>> project, >>>>> along with a healthy diet, reduces your potential for chronic >>>>> lameness >>>>> and boredom. Vote Now at >>>>> http://www.sourceforge.net/community/cca08_______________________________________________ >>>>> Iscsitarget-devel mailing list >>>>> Iscsitarget-devel@... >>>>> https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel >>>> >>>> ------------------------------------------------------------------------- >>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >>>> Studies have shown that voting for your favorite open source >>>> project, >>>> along with a healthy diet, reduces your potential for chronic >>>> lameness >>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >>>> _______________________________________________ Iscsitarget-devel >>>> mailing list Iscsitarget-devel@... https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel >>> -- >>> Ming Zhang >>> >>> >>> @#$%^ purging memory... (*!% >>> http://blackmagic02881.wordpress.com/ >>> http://www.linkedin.com/in/blackmagic02881 >>> -------------------------------------------- >>> >> > -- > Ming Zhang > > > @#$%^ purging memory... (*!% > http://blackmagic02881.wordpress.com/ > http://www.linkedin.com/in/blackmagic02881 > -------------------------------------------- > ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Iscsitarget-devel mailing list Iscsitarget-devel@... https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel |
|
|
Re: IMPORTANT....initiator sensing target daemonrestart
by Ming Zhang-3
::
Rate this Message:
On Thu, 2008-07-03 at 01:12 -0400, Jeff Waller wrote:
> On Jul 2, 2008, at 10:59 AM, Ming Zhang wrote: > > > On Wed, 2008-07-02 at 10:54 -0400, Jeff Waller wrote: > >> On Jul 2, 2008, at 10:33 AM, Ming Zhang wrote: > >> > >>> On Wed, 2008-07-02 at 10:21 -0400, Jeff Waller wrote: > >>>> > >>>> On Jul 2, 2008, at 9:21 AM, Ross S. W. Walker wrote: > >>>> > >>>>> > >>>>> You don't need to restart the target daemon, use ietadm to > >>>>> add/remove targets and luns while the daemon is running. > >>>>> > >>>>> > >>>>> If at some point you do need to restart the target for some > >>>>> reason, > >>>>> make sure to use iptables to drop port unreachable packets, either > >>>>> always, or right before restart and disable right after. > >>>>> > >>>>> > >>>> BTW my mods are coming along, I should have an update on this by > >>>> this > >>>> weekend. There appear > >>>> to be some serious issues to the current implementation. But, > >>>> what's > >>>> this about having to drop packets? > >>>> Can you point to a previous discussion here? > >>> > >>> > >>> search list archive about iptable to help ietd restart. > >> > >> Will do thanks Ming, I might have some followup questions later > >> after > >> having read the thread. > >> > > > > sure. > > Ok I read some threads, and this appears to be a workaround to a bug > in ietd > that it doesn't support reload other than stop-start (as of like last > year) still true, > I take it? The problem is that connection requests are responded to > (connection > refused) as opposed to dropped. iptables is a workaround for that. > > > > > > > >>> > >>> > >>> > >>>>> After adding target or lun, then do a session rescan and it will > >>>>> find the new targets/luns. > >>>>> > >>>>> > >>>> I think his intention is that he should not have to poll, but this > >>>> new > >>>> information should be > >>>> announced. Or maybe he doesn't care, but having read this, I > >>>> think I > >>>> do. > >>>> > >>>> > >>>> What does the protocol have for us in this area? > >>> > >>> as Ross pointed out, use ietadm to add LU without restarting the > >>> ietd. > >>> but current implementation lack the ability to notify ini side > >>> regarding > >>> the new LU, u still have to rescan the session at ini side. > >>> > >>> SCSI protocol covers this with: after target have a new LU, target > >>> send > >>> back a sense with REPORT_LUNS information changed Unit attention. > >>> this > >>> will let ini to reissue the report_luns command. > >> > >> Ok, good deal, the iSCSI protocol does have a mechanism for > >> allowing the > >> target to send change notifications. We simply have to implement it. > > > > sorry, but it is SCSI protocol, not iSCSI protocol... > > Got it. > > > > > > > > >> > >>> > >>> > >>> but (1) iet does not have this. (2) not sure if linux scsi layer at > >>> ini > >>> side support this. > >>> > >>> why not simply add a LU to another target? > >> > >> Administrative complication, maybe. > >> > > > > one LU, one target, give to one ini. u will find it simpler in long > > run. > > especially when u have multiple ini and need access control... of > > course, my personal opinion... > > But what if you want to make available a number of disks, and only > what to specify the configuration information common to all of that > once. Most of the configuration information is based on the target > not the LUN, eh? Additionally, isn't it the target that you can > specify a maximum number of connections (e.g. maximum 10 > users per target) == maximum 10 users/pool of data. iet does NOT support a MAX # of connection limit. > > > > > > > also one lu per target might be faster if you have fast storage > > (>200MB/s) and fast network (like 10Gbps), > > If in your experience, we don't need more than 1 LUN/Target, that > begs the question then, why LUNs exist at all, is this a holdover > from SCSI? i donot say you do not need more than 1 lu per target. i just say iet implementation let 1 lu per target run faster in certain circumstance. as you stated already, there are cases that more than 1U will be better manageable. also for device type other than disk, like tape library, you have to have more LU per target. > > > > > > > > > > >>> > >>> > >>> > >>> > >>>> > >>>> > >>>> -Jeff > >>>>> > >>>>> > >>>>> -Ross > >>>>> > >>>>> > >>>>> ----- Original Message ----- > >>>>> From: iscsitarget-devel-bounces@... > >>>>> <iscsitarget-devel-bounces@...> > >>>>> To: iscsitarget-devel@... > >>>>> <iscsitarget-devel@...> > >>>>> Sent: Wed Jul 02 05:38:28 2008 > >>>>> Subject: [Iscsitarget-devel] IMPORTANT....initiator sensing target > >>>>> daemonrestart > >>>>> > >>>>> Hello, > >>>>> > >>>>> Consider the scenario, > >>>>> > >>>>> "Open-iSCSI" initiator connected to one "IET" target from target > >>>>> machine. > >>>>> > >>>>> Presently 2 LUN's were attached to it. > >>>>> > >>>>> Target machine adds 3rd LUN to the same target which is exposed to > >>>>> increase storage. > >>>>> > >>>>> "Target machine daemon(iscsi-target)" is restarted to make the > >>>>> changes reflect the initiator side. > >>>>> > >>>>> Initiator may/may not be undergoing I/O on the 2 exposed LUN's at > >>>>> that instance. > >>>>> > >>>>> on firing "iscsiadm -m session -P 3",it will show status as > >>>>> "Blocked" for 1-2 seconds indicating that target configuration is > >>>>> changed. > >>>>> > >>>>> Then initiator has to perform "iscsiadm -m session --rescan" to > >>>>> add > >>>>> the 3rd LUN to target already exposed. > >>>>> > >>>>> My question is, > >>>>> > >>>>> 1. Which signal target sends to initiator so that it can know > >>>>> target > >>>>> daemon is restarted?? > >>>>> > >>>>> I want initiator to have access of 3rd LUN after target added > >>>>> it.i.e. on which event,I should run "iscsiadm -m session > >>>>> --rescan"?? > >>>>> > >>>>> 2. One way could be on initiator side,I should write a > >>>>> daemon/program to run "iscsiadm -m session -P 3" continuously to > >>>>> sense if Disk > >>>>> > >>>>> state is "blocked" and iSCSI state is "REOPEN".At that instance, > >>>>> I can run "iscsiadm -m session --rescan" to make changes reflect. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> ____________________________________________________________________ > >>>>> This e-mail, and any attachments thereto, is intended only for use > >>>>> by the addressee(s) named herein and may contain legally > >>>>> privileged > >>>>> and/or confidential information. If you are not the intended > >>>>> recipient of this e-mail, you are hereby notified that any > >>>>> dissemination, distribution or copying of this e-mail, and any > >>>>> attachments thereto, is strictly prohibited. If you have received > >>>>> this e-mail in error, please immediately notify the sender and > >>>>> permanently delete the original and any copy or printout thereof. > >>>>> ------------------------------------------------------------------------- > >>>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > >>>>> Studies have shown that voting for your favorite open source > >>>>> project, > >>>>> along with a healthy diet, reduces your potential for chronic > >>>>> lameness > >>>>> and boredom. Vote Now at > >>>>> http://www.sourceforge.net/community/cca08_______________________________________________ > >>>>> Iscsitarget-devel mailing list > >>>>> Iscsitarget-devel@... > >>>>> https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel > >>>> > >>>> ------------------------------------------------------------------------- > >>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > >>>> Studies have shown that voting for your favorite open source > >>>> project, > >>>> along with a healthy diet, reduces your potential for chronic > >>>> lameness > >>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > >>>> _______________________________________________ Iscsitarget-devel > >>>> mailing list Iscsitarget-devel@... https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel > >>> -- > >>> Ming Zhang > >>> > >>> > >>> @#$%^ purging memory... (*!% > >>> http://blackmagic02881.wordpress.com/ > >>> http://www.linkedin.com/in/blackmagic02881 > >>> -------------------------------------------- > >>> > >> > > -- > > Ming Zhang > > > > > > @#$%^ purging memory... (*!% > > http://blackmagic02881.wordpress.com/ > > http://www.linkedin.com/in/blackmagic02881 > > -------------------------------------------- > > > Ming Zhang @#$%^ purging memory... (*!% http://blackmagic02881.wordpress.com/ http://www.linkedin.com/in/blackmagic02881 -------------------------------------------- ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Iscsitarget-devel mailing list Iscsitarget-devel@... https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel |
| Free Forum Powered by Nabble | Forum Help |