On Thu, 2013-11-07 at 16:16 -0500, Phillip Susi wrote: > On 11/7/2013 1:21 PM, Douglas Gilbert wrote: > > On 13-11-06 08:57 PM, Phillip Susi wrote: > >> Don't bother forcing disks to spin up on resume, as they will do > >> so automatically when accessed, and forcing them to spin up slows > >> down the resume. Add a second bit to the manage_start_stop flag > >> to restore the previous behavior. > > > > SCSI disks when in STOP state do not spin up "automatically when > > accessed". > > The drive does not, but the scsi error handling notices when a command > fails because the drive needs started, starts it, and retries the command.
No disk does, neither SCSI nor ATA. The error handler is not automatically activated for a not ready/initializing command required because of multi-path. We override the default behaviour via allow_restart only for IBM vfc/vscsi and ATA disks. With this patch SCSI devices would no longer ever restart after suspend. > > And your choice of bits looks like it will favour fixing broken > > SATA behaviour but as a by-product break working SCSI disk > > behaviour. > > No, it has nothing to do with sata behavior; it has to do with whether > or not all disk drives should be restarted immediately after a resume, > or only when they are accessed. I happen to have a few older drives > that I very rarely access and would rather they not start up every > time I resume. As Doug said, if you don't restart a SCSI device after resume, it will never get started. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
