From: Alan Stern <stern@rowland.harvard.edu>
To: Jonathan Woithe <jwoithe@just42.net>
Cc: linux-usb@vger.kernel.org
Subject: Re: Samsung T5 SSD: "Synchronize Cache(10) failed" on removal
Date: Sun, 10 Sep 2023 10:35:49 -0400 [thread overview]
Message-ID: <2d11948e-c809-4990-8ebd-e479cc282b90@rowland.harvard.edu> (raw)
In-Reply-To: <ZP2IQxeiAZpC+578@marvin.atrad.com.au>
On Sun, Sep 10, 2023 at 06:41:31PM +0930, Jonathan Woithe wrote:
> Hi Alan
>
> On Sat, Sep 09, 2023 at 12:14:49PM -0400, Alan Stern wrote:
> > > If on the other hand it' is something best fixed, please let me know how I
> > > can assist with this.
> >
> > The most likely situation where this would indicate a real problem would
> > be if you had mounted a filesystem on the drive, written some data, and
> > then unplugged it without unmounting first. If you haven't done that
> > then you don't have to worry about anything.
>
> Thanks for confirming this. The scenarios I've outlined all involve drives
> which have definitely been unmounted before they were unplugged. Thus, so
> long as the unmount has been done then this error can be ignored.
In principle you can write to a drive without mounting it first.
Perhaps the most common examples are creating/modifying a partition
table, doing a filesystem repair, or copying an OS install image. Then
there wouldn't be an unmount to automatically synchronize the cache.
However, I believe the partitioning and repair utilities do their own
cache synchronization, so again it's not an issue in those cases.
Mostly it's just necessary to be careful about your own raw-disk
accesses -- something most of us very rarely do.
> I guess what drew my attention to the message is that USB flash drives do
> not show the "Synchronize Cache(10) failed" error when unplugged. I guess
> the different behaviour may be the result of varying caching arrangements
> (or other low level structural details) across the devices.
Yes. Most likely the flash drives don't claim to have caches, so the
kernel doesn't try to issue a SYNCHRONIZE CACHE command.
> > On the other hand, if you would like to get rid of those annoying error
> > messages, you can do so by telling the kernel that the drive is about to
> > be removed before you unplug it. You do this by writing to the "remove"
> > attribute file in the USB device's sysfs device directory; this is the
> > equivalent of using the "Safely remove a device" button in Windows.
> > Some GUIs may provide an easy-to-use mechanism for doing this, such as
> > an "eject" selection on a device menu.
>
> I've noticed separate "Eject" and "Unmount" items under various desktop
> environments and always wondered why they were separated. Thanks for
> providing the missing information. I personally run a very simple window
> manager (fvwm2) so don't get device menus. If the message gets to me I'll
> look into arranging for the sysfs attribute write. However, knowing now
> that it's essentially a quirk of the way the device interacts with the
> subsystem I will be happy to simply leave things as they are.
>
> Thank you again for taking the time to respond.
You're welcome.
Alan Stern
prev parent reply other threads:[~2023-09-10 14:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-09 8:06 Samsung T5 SSD: "Synchronize Cache(10) failed" on removal Jonathan Woithe
2023-09-09 16:14 ` Alan Stern
2023-09-10 9:11 ` Jonathan Woithe
2023-09-10 14:35 ` Alan Stern [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=2d11948e-c809-4990-8ebd-e479cc282b90@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=jwoithe@just42.net \
--cc=linux-usb@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