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: SHA512

On 11/17/2013 06:54 PM, Douglas Gilbert wrote:
> Even if the SCSI EH code does spin-up the disk, it is inefficient
> and undesirable to send a device into EH for what is a normal,
> predictable situation (i.e. that a SCSI disk will need a START STOP
> UNIT (start) command as part of a resume operation).

The device doesn't need the START STOP UNIT command as part of the
resume operation; it only needs it prior to other commands.  What is
inefficient is starting up drives that won't be accessed.  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.

> A big server machine could have thousands of SCSI disks (many
> potentially virtual). Sending them all into EH during a resume
> would be a really good test for EH, but horrible for performance.
> If I was designing the SCSI EH I would probably assume not all
> disks would go into EH at roughly the same time. Also if that many
> devices went into EH on the same controller (HBA) it might be
> reasonable to assume that the controller they share needs
> resetting.

They don't all go into EH during resume; they go into EH when they are
finally accessed, which for many of them is probably not for some
time.  This also sounds like a bit of speculation and/or hand waving.
 Is there really a problem with multiple devices going into EH?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJSiWgGAAoJEJrBOlT6nu75klwIAK29G/p+pZhccbfXBnIpvq8m
oIuCOCgMjIbSkJDEo52BiEf6d52tK8aQNTXcHZCC7T2/yvWV55vGHeXbxZ9iospp
IsoJOMLtcM9p5DHZido5RubXrq63cU3yGovGbsp834Ij+d51HB17Dh4Dc1iU/mQV
4X6623hH0ooHWjmtoK6l5rGfKxkPe2ZKP3RAOpW5hiFaGPFWpc375Kukf6Zvw161
mBRfdWtc1SRGme/dcEEggH5t20R0kJteAey4RLF77W8VcooVbE3zCESpVNwqHxYK
6Mc67avVzMyk+Cmb2IN9iMB05oPDIzhKU4kStyYKVGqiS1D2NHUUi56GZTN5Ry0=
=kmdB
-----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