From: Winston Wen <wentao@uniontech.com>
To: Laurence Oberman <loberman@redhat.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: unsafe shutdown during system restart
Date: Thu, 25 Apr 2024 08:56:34 +0800 [thread overview]
Message-ID: <2FA6AD2D5F670978+20240425085634.241b5616@winn-pc> (raw)
In-Reply-To: <134b44cec24e0480f8df4e9bc0f0c1e28df24887.camel@redhat.com>
On Wed, 24 Apr 2024 12:52:35 -0400
Laurence Oberman <loberman@redhat.com> wrote:
> On Wed, 2024-04-24 at 15:47 +0800, Winston Wen wrote:
> > Hi,
> >
> > I noticed that my hard drive had an unsafe shutdown during system
> > restart. I have done some related research and found that a stop
> > command will be sent to the hard drive during system shutdown, but
> > not during system restart.
> >
> > Is there a way to avoid the unsafe shutdown? Or is it the
> > responsibility of the firmware to send the stop command to the hard
> > drive before shutdown?
> >
> > And why doesn't the kernel send the stop command in system restart?
> > I am indeed curious about it, and I would greatly appreciate it if
> > anyone
> > could help me clarify it. :)
> >
> > Thanks!
> >
> Which Distro are you using, where you are seeing this.
> And what is the kernel version.
>
> Regards
> Laurence
>
>
Hi Laurence,
Thank you for your reply!
I found it on Deepin 20, with a 4.19 kernel and a sata disk from a
Chinese manufacturer.
After undergoing a disk stress test (fio), I found that the write
performance of the disk was poor for a period of time after rebooting.
The disk manufacturer did some troubleshooting and tracing, and
told me that the disk did not receive the stop command during the
reboot process, so it will take some time to rebuild the internal data
structure after being powered on again.
They showed me a list of commands they traced, and during the shutdown
process, they would receive a STANDBY IMMEDIATE command after FLUSH
CACHE EXT, but not during the restart process.
Then I did some tests to confirm. I enabled dev.scsi.logging_level in
the debian12 virtual machine (with 6.6 kernel) and collected logs on
system reboot and shutdown. During the shutdown, the "Stopping disk"
log can be seen, but it is not present during the reboot.
I also hope to do some comparative testing on other hard drives, but I
did not find the unsafe shutdown related field in the smart information
of the sata disk (maybe I just missed it), so I give up.
I am not an expert in scsi, so I took a temporary look at the relevant
code and found sd_shutdown based on the "Stopping disk" log, and I also
browsed some related commits and discussions.
I feel that this may be a firmware implementation issue, but I'm not so
sure, so I come to the community to ask for some advice.
Just now, I tested another machine (also Deepin system, but American
Megatrends firmware), the Seagate's sata disk does not increase
power_cycle_count during the reboot. I think maybe this is the
right behavior of the firmware.
Welcome any suggestions and corrections, and thanks for all replies!
--
Thanks,
Winston
prev parent reply other threads:[~2024-04-25 0:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-24 7:47 unsafe shutdown during system restart Winston Wen
2024-04-24 16:52 ` Laurence Oberman
2024-04-25 0:56 ` Winston Wen [this message]
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=2FA6AD2D5F670978+20240425085634.241b5616@winn-pc \
--to=wentao@uniontech.com \
--cc=linux-scsi@vger.kernel.org \
--cc=loberman@redhat.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).