From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Richter Subject: Re: [linux-pm] Power management for SCSI Date: Wed, 20 Aug 2008 01:22:49 +0200 Message-ID: <48AB55C9.3010106@s5r6.in-berlin.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Alan Stern Cc: Oliver Neukum , Pavel Machek , linux-pm@lists.linux-foundation.org, James.Bottomley@hansenpartnership.com, Linux-pm mailing list , kernel list , teheo@novell.com List-Id: linux-pm@vger.kernel.org Alan Stern wrote: > On Tue, 19 Aug 2008, Oliver Neukum wrote: > >>> More to the point is whether you should ever suspend any of these >>> devices if there can be multiple initiators. But that's a separate >>> question. >> But one that needs to be addressed. > > One possibility is to have an attribute flag for SCSI transport > classes, indicating whether the transport supports multiple initiators. > > Besides, isn't this already an issue? What happens when someone does a > system suspend or hibernate? Don't the attached disk drives get spun > down, even if there are other initiators on the same SCSI bus? In (fw-)sbp2, we have for example this simple code: static int sbp2_scsi_slave_configure(struct scsi_device *sdev) { ... if (sbp2_param_exclusive_login) sdev->manage_start_stop = 1; ... By setting the exclusive_login module parameter from Y (default) to N, multiple initiators per logical unit become possible. We are too lazy to check whether there are actually other initiators at a given moment; after all they can come and go all the time. So the simplest strategy is to suppress managed START STOP when concurrent initiators are _possible_. I suppose though that all multiple initiator capable transports have ways to query the presence of other initiators at any given time; but I don't think the respective effort is justified. > (And is this really a problem? If an error occurs because a drive is > spun down when some other device tries to access it, that other device > should simply spin the drive back up again.) The high latency may be a problem. -- Stefan Richter -=====-==--- =--- =-=-- http://arcgraph.de/sr/