From: Phillip Susi <phill@thesusis.net>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: linux-ide@vger.kernel.org
Subject: Re: [PATCH v8 04/23] scsi: sd: Differentiate system and runtime start/stop management
Date: Sat, 21 Oct 2023 13:56:03 -0400 [thread overview]
Message-ID: <87sf63hnbg.fsf@vps.thesusis.net> (raw)
In-Reply-To: <ff334ece-ca5b-490b-91d7-6bb51fd2e2b3@kernel.org>
Damien Le Moal <dlemoal@kernel.org> writes:
> In the hybernate (suspend to disk) case, yes, but not in the suspend
> to RAM
No; in BOTH cases. In S3, the PSU is shut down and only aux power is
maintained to keep the sdram in auto refresh mode. The main power rails
that power the disk drives are shut down. The drive can not tell
whether suspend to disk or suspend to ram was used.
> Depends on the disk implementation. Not all disks put their metadata on media.
> So some disks can start replying to commands like IDENTIFY even with
> the disks
Yes, the standard allows either way and I'm sure that there are both out
there, I just thought that the incomplete IDENTIFY because it needs the
media case was the more common of the two. At least I think my WD
drives do that.
> not fully spun up yet. This difference shows up with (sometimes) seeing
> "IDENTIFY failed" due to a timeout on resume. I have old drives that are slow to
> spinup and show that. But that is handled with the retries with increased
> timeouts. I think it would be nice to patch that though, with longer timeout for
> IDENTIFY on resume, to avoid these error messages.
Isn't the timeout like 10 or 20 seconds and typical spinup times only
3-4? Still, yes, a little longer timeout for the IDENTIFY after resume
might be a good idea.
> I am not following. What problem are you trying to fix ?
I would like my archive disks to PuiS and just remain in standby after a
system resume, because I hardly ever access them. Thus it's putting
unneccesary wear and tear on them to spin up, then spin right back down
every time I system suspend and resume.
I suspend/resume my desktop at least once a day, but I can see this
being an even larger problem on a NAS that wants to use opportunistic
suspend to save power. Just because you say, want to connect to the
management web interface, or have a scheduled cron job every hour that
forces it to wake up from system suspend does not mean that the disk, or
all disks, need to spin up each time.
Laptops also tend to system suspend/resume more frequently, it it seems
to be becoming at least somewhat common to have a HDD for archive, and an
SSD/NVME to run the system on, and the HDD is not likely going to be
accessed every time the system suspends and resumes, so why bother
spinning it up automatically?
next prev parent reply other threads:[~2023-10-21 17:56 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <c0b086ab-dcd5-4b7b-b931-4d407dd7ad47()kernel!org>
2023-10-12 19:01 ` [PATCH v8 04/23] scsi: sd: Differentiate system and runtime start/stop management Phillip Susi
2023-10-13 0:57 ` Damien Le Moal
2023-10-13 14:36 ` Phillip Susi
2023-10-15 22:09 ` Damien Le Moal
2023-10-21 17:56 ` Phillip Susi [this message]
2023-10-23 5:49 ` Damien Le Moal
2023-11-03 18:05 ` Phillip Susi
2023-11-03 23:01 ` Phillip Susi
2023-11-06 2:32 ` Damien Le Moal
2023-11-07 13:27 ` Phillip Susi
2023-11-07 21:59 ` Damien Le Moal
2023-11-08 22:07 ` Phillip Susi
2023-11-06 3:00 ` Damien Le Moal
2023-11-07 13:45 ` Phillip Susi
2023-11-07 21:48 ` Phillip Susi
2023-11-07 23:11 ` Damien Le Moal
2023-11-08 22:15 ` Phillip Susi
2023-11-09 22:09 ` Phillip Susi
2023-11-09 22:57 ` Damien Le Moal
2023-11-10 16:41 ` Phillip Susi
2023-11-10 0:43 ` Damien Le Moal
2023-11-07 22:13 ` Damien Le Moal
2023-11-08 22:25 ` Phillip Susi
2023-09-27 14:18 [PATCH v8 00/23] Fix libata suspend/resume handling and code cleanup Damien Le Moal
2023-09-27 14:18 ` [PATCH v8 04/23] scsi: sd: Differentiate system and runtime start/stop management Damien Le Moal
2023-09-27 19:50 ` Martin K. Petersen
2023-10-10 13:09 ` Phillip Susi
2023-10-10 14:04 ` Damien Le Moal
2023-10-15 16:14 ` Phillip Susi
2023-10-15 22:44 ` Damien Le Moal
2023-10-16 12:39 ` Phillip Susi
2023-10-16 12:55 ` Damien Le Moal
2023-10-17 18:03 ` Phillip Susi
2023-10-17 23:32 ` Damien Le Moal
2023-10-20 19:00 ` Phillip Susi
2023-10-18 6:16 ` Damien Le Moal
2023-10-20 21:23 ` Phillip Susi
2023-10-23 5:51 ` Damien Le Moal
2023-10-26 21:21 ` Phillip Susi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sf63hnbg.fsf@vps.thesusis.net \
--to=phill@thesusis.net \
--cc=dlemoal@kernel.org \
--cc=linux-ide@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox