Re: [Scst-devel] Scst-devel Digest, Vol 132, Issue 14

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi
I'm testing the device Active new option
but i can not change the state of this option
example i change the Alua state to "active" and preferred to 1, but device
remains active = 0

[  899.727542] [4619]: scst: __scst_tg_set_state:1006:Changed ALUA state of
ini1/sbb2 into active
[  911.057702] [4619]: scst: __scst_tg_set_preferred:1078:Changed preferred
state of ini1/sbb2 from 0 into 1

with this simple configuration

HANDLER vdisk_blockio {
    DEVICE ini1_vol1 {
        active 0
        filename /dev/zvol/POOL1/vol1
        prod_id SCST
        size 10737418240
        size_mb 10240
    }
}

TARGET_DRIVER copy_manager {
    TARGET copy_manager_tgt {
        LUN 0 ini1_vol1
    }
}

TARGET_DRIVER iscsi {
    enabled 0
}

TARGET_DRIVER qla2x00t {
    TARGET 21:00:00:24:ff:2f:54:66 {
        HW_TARGET

        enabled 1
        rel_tgt_id 201

        GROUP ini1 {
            LUN 0 ini1_vol1

            INITIATOR 21:00:00:e0:8b:9b:b7:d0

            io_grouping_type 201
        }
    }
}

DEVICE_GROUP ini1 {
    DEVICE ini1_vol1

    TARGET_GROUP sbb2 {
        group_id 2
        preferred 1
        state active

        TARGET 21:00:00:24:ff:2f:54:66
    }
}

Any help is welcome

Jose


On Tue, Jun 6, 2017 at 9:48 PM, <scs...@li...>
wrote:

> Send Scst-devel mailing list submissions to
>         scs...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/scst-devel
> or, via email, send a message with subject or body 'help' to
>         scs...@li...
>
> You can reach the person managing the list at
>         scs...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Scst-devel digest..."
>
>
> Today's Topics:
>
>    1. Unable to build scst on el7 clone (Tren Blackburn)
>    2. Re: Conglomerate LUN's. (Dr. Greg Wettstein)
>    3. Re: Active/Passive Clusters, Thinking Outloud
>       (Vladislav Bolkhovitin)
>    4. Re: Active/Passive Clusters, Thinking Outloud
>       (Vladislav Bolkhovitin)
>    5. Re: Active/Passive Clusters, Thinking Outloud (Bart Van Assche)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 5 Jun 2017 17:32:32 -0700
> From: Tren Blackburn <ia...@th...>
> To: scs...@li...
> Subject: [Scst-devel] Unable to build scst on el7 clone
> Message-ID:
>         <CAM0SCo+8n+cTw9EWZeOP8vmbCA=hfa4HGk6A-=Q01hHLVW7Prg@mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi List;
>
> I?m kind of stuck. I?ve been attempting to compile SCST, but I run
> into the same problem with every version I try:
>
> make[4]: Entering directory `/usr/src/kernels/3.10.0-327.18.2.vz7.15.2'
> ? LD ? ? ?/usr/src/packages/BUILD/scst-3.3.0.7204/scst/src/built-in.o
> ? CC [M] ?/usr/src/packages/BUILD/scst-3.3.0.7204/scst/src/scst_main.o
> ? CC [M] ?/usr/src/packages/BUILD/scst-3.3.0.7204/scst/src/scst_targ.o
> ? CC [M] ?/usr/src/packages/BUILD/scst-3.3.0.7204/scst/src/scst_lib.o
> ? CC [M] ?/usr/src/packages/BUILD/scst-3.3.0.7204/scst/src/scst_sysfs.o
> ? CC [M] ?/usr/src/packages/BUILD/scst-3.3.0.7204/scst/src/scst_mem.o
> /usr/src/packages/BUILD/scst-3.3.0.7204/scst/src/scst_mem.c: In
> function 'scst_sgv_pools_init':
> /usr/src/packages/BUILD/scst-3.3.0.7204/scst/src/scst_mem.c:1805:14:
> error: 'struct shrinker' has no member named 'shrink'
> ? sgv_shrinker.shrink = sgv_shrink;
>
> I get this sgv_shrinker compile error regardless of what version I
> try, including the latest from Trunk.
>
> The system is Virtuozzo Linux 7.2 (it?s a redhat clone with openvz
> added). In my research, the only time I found this issue historically
> was in 2013:
>
> https://sourceforge.net/p/scst/mailman/scst-devel/
> thread/52B...@vl.../
>
> I?m kind of pulling my hair out since I?m not sure what the issue is.
> Any direction would be appreciated!
>
> Thanks!
>
> Tren.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 6 Jun 2017 03:36:23 -0500
> From: "Dr. Greg Wettstein" <gr...@wi...>
> To: Vladislav Bolkhovitin <vs...@vl...>,
>         scs...@li...
> Subject: Re: [Scst-devel] Conglomerate LUN's.
> Message-ID: <201...@wi...>
>
> On Jun 2,  7:39pm, Vladislav Bolkhovitin wrote:
> } Subject: Re: [Scst-devel] Conglomerate LUN's.
>
> > Hi Greg,
>
> Good morning to everyone.
>
> > Yes, patches in those areas are very welcome.
>
> First of all a thank you to everyone who responded both on the list
> and privately with assistance in respect to providing pointers to
> available documentation.
>
> I think we have enough to go on to start work on the design of an
> initial implementation.  Word from the underground suggests that the
> 'big-iron' storage vendors have struggled a bit with implementation so
> we will see what devils are in the details.
>
> Before we wade too deep into this we wanted to throw the table open
> for discussion on what the community believes the model should be for
> implementing conglomerate LUN's.  On the VMware/EMC side of the
> equation the implementation of conglomerate LUN's is heavily tied to a
> VASA provider implementation which is at a different level of
> abstraction then the target server itself.
>
> At a minimum our implementation of a LUN is going to have to change,
> or need at least an additional data element.  In SCST we currently
> treat LUN's as an opaque 64 bit number and in the case of conglomerate
> LUN's our notion of a LUN would seem to be the administrative LUN which
> will have potentially large numbers of subordinate LUN's associated
> with them.
>
> So if anyone has any thoughts put them on the table so we can have a
> consensus with respect to implementation.
>
> > Vlad
>
> Have a good day.
>
> Greg
>
> }-- End of excerpt from Vladislav Bolkhovitin
>
> As always,
> Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
> 4206 N. 19th Ave.           Specializing in information infra-structure
> Fargo, ND  58102            development.
> PH: 701-281-1686
> FAX: 701-281-3949           EMAIL: gr...@en...
> ------------------------------------------------------------
> ------------------
> "One of the reporters asked if the could "see" the INTERNET worm.
>  They tried to explain that it wasn't something that you could actually
>  see but is was merely a program that was running in the background.
>  One of the reporters asked, 'What if you had a color monitor?'"
>                                 -- UNKNOWN
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 06 Jun 2017 12:26:45 -0700
> From: Vladislav Bolkhovitin <vs...@vl...>
> To: Marc Smith <mar...@pa...>
> Cc: "scs...@li..."
>         <scs...@li...>
> Subject: Re: [Scst-devel] Active/Passive Clusters, Thinking Outloud
> Message-ID: <593...@vl...>
> Content-Type: text/plain; charset=windows-1252
>
> Marc Smith wrote on 06/06/2017 06:41 AM:
> >     > Effectively the SCST "device" is the same on both nodes (same
> device
> >     > name, same identifier generated/used). The ALUA configuration and
> >     > states are kept consistent by the cluster RA, so those target
> >     > interfaces local on node A, are remote on node B and vice versa.
> >     >
> >     > So the ALUA state can be active on both nodes because its for
> >     > different sets of target interfaces (NOT the same sets of target
> >     > interfaces).
> >
> >     I see your problem. You don't need to mirror targets from the other
> node. It's
> >     overkill. If another node went down, all its targets got down as
> well, no problem.
> >     Initiator(s) will just pick up the other, alive targets. When the
> failed node gets
> >     back, the initiator(s) will detect it and add back. Just ensure that
> ALUA states set
> >     right between nodes: active ones on the active node and passive ones
> on the passive
> >     node.
> >
> >     Imagine, you are using HW targets, which you can't similarly mirror.
> Then your approach
> >     would fail, no way to make it work.
> >
> >     Vlad
> >
> > Okay, thanks, understood. However we're still unable to make the
> "active" attribute
> > change it's value when using just one target group per device group (and
> changing the
> > ALUA state to active/standby). I'll test with the latest revision from
> trunk and add
> > some monitoring lines and see if I can figure out what's going on. Would
> it be trivial
> > to make it so the "active" attribute can be modified directly by a user
> via sysfs? Or
> > are the changes considerable to do that?
>
> The "active" attribute changes its values automatically following ALUA
> state changes. I
> made it read-only on purpose to prevent confusions similar as we have with
> the ALUA
> states. Its the only goal to be able first time open or not open
> underlying block
> device on initialization. Then it all supposed to be automatic.
>
> I would be really surprised, if you actually need change this attribute.
>
> Vlad
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 06 Jun 2017 12:27:04 -0700
> From: Vladislav Bolkhovitin <vs...@vl...>
> To: Bart Van Assche <Bar...@sa...>,
>         "mar...@pa..." <mar...@pa...>
> Cc: "scs...@li..."
>         <scs...@li...>
> Subject: Re: [Scst-devel] Active/Passive Clusters, Thinking Outloud
> Message-ID: <593...@vl...>
> Content-Type: text/plain; charset=windows-1252
>
> Hi Bart,
>
> Bart Van Assche wrote on 06/06/2017 07:27 AM:
> > On Mon, 2017-06-05 at 21:22 -0700, Vladislav Bolkhovitin wrote:
> >> You don't need to mirror targets from the other node. It's overkill.
> >
> > Hello Vlad,
> >
> > ESX initiators don't fail-over without such mirroring of the ALUA
> information.
> > As far as I know ESX is the only initiator operating system that
> requires such
> > mirroring.
>
> It's something interesting. Can you elaborate? What does not work and how?
>
> My knowledge clearly states that VMware has all required support for ALUA
> since 2009
> (since vSphere 4.0).
>
> Just in case, failover between multiple paths, i.e. switch to another
> path, if this
> path failed, is not related to ALUA at all. Multipathing was ability of
> VMware since
> ancient days. ALUA only needed and was added for to tell it which path(s)
> from
> available ones to use.
>
> Thanks,
> Vlad
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 6 Jun 2017 20:14:22 +0000
> From: Bart Van Assche <Bar...@sa...>
> To: "vs...@vl..." <vs...@vl...>, "mar...@pa..."
>         <mar...@pa...>
> Cc: "scs...@li..."
>         <scs...@li...>
> Subject: Re: [Scst-devel] Active/Passive Clusters, Thinking Outloud
> Message-ID: <149...@sa...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, 2017-06-06 at 12:27 -0700, Vladislav Bolkhovitin wrote:
> > Bart Van Assche wrote on 06/06/2017 07:27 AM:
> > > On Mon, 2017-06-05 at 21:22 -0700, Vladislav Bolkhovitin wrote:
> > > > You don't need to mirror targets from the other node. It's overkill.
> > >
> > > Hello Vlad,
> > >
> > > ESX initiators don't fail-over without such mirroring of the ALUA
> information.
> > > As far as I know ESX is the only initiator operating system that
> requires such
> > > mirroring.
> >
> > It's something interesting. Can you elaborate? What does not work and
> how?
>
> Hello Vlad,
>
> When we tested interoperability between the ION software and ESXi we
> noticed
> that failover did not work properly until we made the remote port state
> available to ESXi. Some of this discussion can be found in
> https://essjira.sandisk.com/browse/ION-347. If I remember correctly
> switching
> from the "unavailable" to "standby" state together with making the remote
> port
> state available was sufficient to realize interoperability with ESXi.
>
> Bart.
>
>
> ------------------------------
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Scst-devel mailing list
> https://lists.sourceforge.net/lists/listinfo/scst-devel
>
>
> ------------------------------
>
> End of Scst-devel Digest, Vol 132, Issue 14
> *******************************************
>