Re: [PATCH] make fc transport removal of target configurable

Hannes Reinecke
2006-06-14T07:21:45Z

Michael Reed wrote:
>
> James Bottomley wrote:
>> Since the rest of
>> our infrastructure is already event driven, or migrating that way, I
>> really don't see value in introducing an anomaly like this purely for
>> fibre channel.
>
> It's tough on fibre channel, being first. :)
>
> Among the benefits of this patch is the purchase of time. With the fc
> infrastructure the way it is, you're assured of forcing developers to
> "publish or perish". That may be the intended desire. It just doesn't
> seem fair to the users who have to deal with this. It makes sense to
> me to implement the event driven infrastructure in such a way that
> it's more complete when released. If infrastructure is going to be
> removed, then "applications" have to be adjusted to accommodate this.
> It shouldn't be, oh by the way, your driver/app is now broken, hurry up
> and fix it or your users will complain. [End Of Rant]. My patch
> buys time. Change the default so that the remove on disconnect has
> to be consciously overridden. Remove the variable when the supporting
> infrastructure is in place. Put out a message indicating that the
> option of not removing the infrastructure is "going away" in a future
> release. Provide an orderly transition. Insure domestic tranquility.
> Promote the general welfare. :) I'm happy to adjust the patch
> to accommodate any of these suggestions if they are deemed acceptable.
>
And I can only _strongly_ agree with Mike here.
Yes, the infrastructure is moving towards dynamic device configuration.
But no, we're not there yet. Not by a long way.
Neither of the current volume managers (ie LVM2, EVMS, and even md to
some extend) are capable of dynamic reconfiguration.
Of course they sort of work nowadays, but the general idea of LVM2 and
EVMS is still that _all_ devices are available during setup.

And I don't even want to _think_ of the implications of running 'vgscan'
from a udev rule. So Mike's patch would allow those application to run
properly for the time being.

In general I agree with the dev_loss_tmo mechanism. But by enforcing it
we'll only make it easier for the developers of LVM2 et al to put the
blame on us (on the grounds of 'you broke it, you fix it') instead of
coaxing them to change their applications to accept dynamic device
configuration.

Cheers,

Hannes
--
Dr. Hannes Reinecke hare@suse.de
SuSE Linux Products GmbH S390 & zSeries
Maxfeldstraße 5 +49 911 74053 688
90409 Nürnberg http://www.suse.de
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html