Doron Shoham wrote:
> Mike Christie wrote:
>> Doron Shoham wrote:
>>> Mike Christie wrote:
>>>> Doron Shoham wrote:
>>>>> Divide node parameters into 3 categories:
>>>>> a. Immutable - properties that are not allowed to change at all.
>>>>> b. Immediate - properties that are allowed to change and take effect
>>>>> immediately.
>>>>> c. Deferred - properties that are allowed to change but will take
>>>>> effect only next
>>>>> session.
>>>>>
>>>>> @@ -588,13 +588,22 @@ static int idbm_verify_param(recinfo_t *info,
>>>>> char *name)
>>>>> continue;
>>>>>
>>>>> log_debug(7, "verify %s %d\n", name, info[i].can_modify);
>>>>> - if (info[i].can_modify)
>>>>> + if (info[i].can_modify == ATTR_IMMEDIATE)
>>>>> return 0;
>>>>> - else {
>>>>> - log_error("Cannot modify %s. It is used to look up "
>>>>> - "the record and cannot be changed.", name);
>>>>> - return EINVAL;
>>>>> + else if (info[i].can_modify == ATTR_DEFERRED) {
>>>>> + if (is_active == 0)
>>>>> + return 0;
>>>>> + else {
>>>>> + log_error("Cannot modify %s. Please logout before
>>>>> modifing it", name);
>>>>> + return EINVAL;
>>>>> + }
>>>>> + }
>>>>> + else if (info[i].can_modify == ATTR_IMMUTABLE) {
>>>>> + log_error("Cannot modify %s. This value is immutable "
>>>>> + "and cannot be modified", name);
>>>>> + return EINVAL;
>>>>> }
>>>> I was thinking about this and there is no reason that we cannot update
>>>> the values that are marked ATTR_DEFERRED when a session is logged in.
>>>> The description of C) in the first snippet and what we do in
>>>> idbm_verify_param do not match up, because idbm_verify_param is not
>>>> going to let you update the value if we are logged in. Maybe we just
>>>> want to print a warning letting the user know that they have to relogin
>>>> to use the new value.
>>> Yes, you are right.
>>> The description should have been something like:
>>> Deferred - properties that are allowed to be changed only while
>>> session is not active. They will take effect next session.
>>>
>>> If we let people to change them while in active session it can be
>>> confusing - after the change, if someone will query the node properties
>>> he will see the new parameters while these parameters are not
>>> the "actual" parameters which the session is used.
>> I think this is fine because the node record values are what is stored
>> in the db. It is not supposed to be what we are using now. session mode
>> should display the values we negotiated for and what was requested.
>>
>> Also, if you are doing iscsi boot you will never be able to change a
>> value for the session used for root.
>
> When using iscsi boot, I think that changing the node parameters
> while logged in will not effect next session
No, it will :) For Fedora/RHEL, iscsistart only takes the basic settings
to get booted. When iscsid starts up it will then look in the db for all
the other settings like timers, segmentlengths, queue depths, etc and
resetup the session to use them. For suse, I think they copy the values
from the db to the initrd so either way for those two distros we need to
be able to edit a running sessions db values for the next startup and we
cannot bring down the session because it is root.
> (you will have to change the default iscsi boot parameters).
>
Yeah, unfortunately the boot/root params are picked up from the db.
> Another solution is to add -f flag (force).
> Using this flag will change the parameter while in active session -
> still it will display a warning message that the change will only
> effect the next session.
That sounds fine.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---
