Re: [PATCH 1/3] sd: don't bother spinning up disks on resume

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/17/2013 8:06 PM, Phillip Susi wrote:
> I don't see anything particularly inefficient about issuing the
> command in the eh path ( in fact, libata always uses the eh path to
> handle power management ).  You can of course, use the
> manage_start_stop flag to have the disk start on resume if you
> really want.

Yikes, I think I see now why scsi eh is so bad: the entire host, not
just the device is quiesced.

I suppose now the question is how to issue the START STOP UNIT from
sd_prep_fn()?  I gather you can't just call scsi_execute_req() from
there?  Is there maybe a way to insert a START STOP UNIT request into
the queue ahead of the current request being prepped?  Can
sd_prep_fn() be called concurrently on multiple cpus?  Hrm.. what
about TCQ?  Would it be bad if the original request were queued ( to
the drive ) before the START STOP UNIT command completed?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSijguAAoJEJrBOlT6nu75AlIH/3n1XFrWWjU2D209hwaBlRCu
OHdAI40OUW0dqRrF7hyhH62X6SmDFG9pkZcCeZUNmSOEBtvkVjxJRv2VvpXpQL50
xXEiLCLukOYWG7krnVhD1BCrt9SfAjMsCpWmbC14m3epCWd9OQNFfU9vqU7mW18b
2NJPBukq+l8nzZtCl+8UMIQxH4RSkceJs3X7y4PhM65nN4kDMmJUABjJhHBZX30/
MQqu6pu2AW6Wf6SH0Sh1qIWfu45cIneuSDRP9qK5U/9902vhmGCLlt4zgbow8CQh
muspp8A+bhcVQAJVdZvHz9gQMHS0dDRjLgBE23Yik0t+zBl0wvoFsaAG4BEi0lY=
=6HCd
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux