linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Steigerwald <martin@lichtvoll.de>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: stable@vger.kernel.org, regressions@lists.linux.dev,
	linux-usb@vger.kernel.org,
	"Holger Hoffstätte" <holger@applied-asynchrony.com>,
	linux-bcachefs@vger.kernel.org, linux-block@vger.kernel.org
Subject: Re: I/O errors while writing to external Transcend XS-2000 4TB SSD
Date: Thu, 15 Feb 2024 12:09:20 +0100	[thread overview]
Message-ID: <1979818.usQuhbGJ8B@lichtvoll.de> (raw)
In-Reply-To: <ypeck262h6ccdnsxzo46vydzygh2y6coe3d4mvgermaaeo5ygg@4nvailbg7ay3>

Kent Overstreet - 12.02.24, 21:42:26 CET:

[thoughts about whether a cache flush / FUA request with write caches 
disabled would be a no-op anyway]

> > I may test the Transcend XS2000 with BTRFS to see whether it makes a
> > difference, however I really like to use it with BCacheFS and I do not
> > really like to use LUKS for external devices. According to the kernel
> > log I still don't really think those errors at the block layer were
> > about anything filesystem specific, but what  do I know?
> 
> It's definitely not unheard of for one specific filesystem to be
> tickling driver/device bugs and not others.
> 
> I wonder what it would take to dump the outstanding requests on device
> timeout.

I got some reply back from Transcend support.

They brought up two possible issues:

1) Copied to many files at once. I am not going to accept that one. An 
external 4 TB SSD should handle writing 1,4 TB in about 215000 files, 
coming from a slower Toshiba Canvio Basics external HD, just fine. About 
90000 files was larger files like sound and video files or installation 
archives. The rest is from a Linux system backup, so smaller files. I 
likely move those elsewhere before I try again as I do not need these on 
flash anyway. However if the amount of files or data matters I could never 
know what amount of data I could write safely in one go. That is not 
acceptable to me.

2) Power management related to USB port. Cause I am using a laptop. It may 
have been that the Linux kernel decided to put the USB port the SSD was 
connected to into some kind of sleep state. However it was a constant 
rsync based copy workload. Yes, the kernel buffers data and the reads from 
Toshiba HD should be quite a bit slower than the Transcend SSD could 
handle the writes. I saw now more than 80-90 MiB/s coming from the hard 
disk. However I would doubt this lead to pauses of write activity of more 
than 30 seconds. Still it could be a thing.

Regarding further testing I am unsure whether to first test with BTRFS on 
top of LUKS – I do not like to store clear text data on the SSD – or with 
BCacheFS plus fixes which are 6.7.5 or 6.8-rc4 in just in the case the flush 
handling fixes would still have an influence on the issue at hand.

First I will have a look on how to see what USB power management options 
may be in place and how to tell Linux to keep the USB port the SSD is 
connected to at all times.

Let's see how this story unfolds. At least I am in no hurry about it.

Best,
-- 
Martin



  reply	other threads:[~2024-02-15 11:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-11 15:42 I/O errors while writing to external Transcend XS-2000 4TB SSD Martin Steigerwald
2024-02-11 16:02 ` Holger Hoffstätte
2024-02-11 17:06   ` Martin Steigerwald
2024-02-11 18:51     ` Kent Overstreet
2024-02-12 15:52       ` Martin Steigerwald
2024-02-12 20:42         ` Kent Overstreet
2024-02-15 11:09           ` Martin Steigerwald [this message]
2024-02-15 15:19             ` Alan Stern
2024-02-15 15:36               ` Martin Steigerwald
2024-03-15  9:08       ` Martin Steigerwald

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=1979818.usQuhbGJ8B@lichtvoll.de \
    --to=martin@lichtvoll.de \
    --cc=holger@applied-asynchrony.com \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-bcachefs@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=regressions@lists.linux.dev \
    --cc=stable@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;
as well as URLs for NNTP newsgroup(s).