From: Marc Joliet <marcec@gmx.de>
To: linux-btrfs@vger.kernel.org
Subject: Re: My first attempt to use btrfs failed miserably
Date: Mon, 03 Feb 2020 20:01:18 +0100 [thread overview]
Message-ID: <2497374.lGaqSPkdTl@thetick> (raw)
In-Reply-To: <CAJCQCtRhTWJuF_=BC0Ak2UtU7RcT2xruHpkYew6zSz2jH3916A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]
Am Montag, 3. Februar 2020, 17:12:17 CET schrieben Sie:
> > Yeah, I found out some errors in dmesg suggesting this:
> > [ 370.569700] usb 2-1: reset SuperSpeed Gen 1 USB device number 2
> > using xhci_hcd
> > [ 428.820969] usb 2-1: reset SuperSpeed Gen 1 USB device number 2
> > using xhci_hcd
> > [ 473.621875] usb 2-1: reset SuperSpeed Gen 1 USB device number 2
> > using xhci_hcd
> > [ 618.254211] usb 2-1: reset SuperSpeed Gen 1 USB device number 2
> > using xhci_hcd
> > [ 664.334958] usb 2-1: reset SuperSpeed Gen 1 USB device number 2
> > using xhci_hcd
>
> I get these with a very common USB-SATA enclosure bridge chipset,
> plugged directly into an Intel NUC. I also sometimes see dropped
> writes. When I use a Dyconn USB hub (externally powered) it never
> happens. I'm not a USB expert, but my understanding is a hub isn't a
> simple thing, it's reading and rewriting the whole stream to and from
> host and device. So any peculiarities between them tend to get cleaned
> up.
FWIW, I used to see errors like this with my external HDD (3TB Toshiba), but
not anymore after I increased its device timeout, i.e., its SCSI command
timeout, to 3 minutes (following a recommendation on the Debian wiki).
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2020-02-03 19:06 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-02 12:45 My first attempt to use btrfs failed miserably Skibbi
2020-02-02 12:56 ` Qu Wenruo
2020-02-02 13:22 ` Stephan von Krawczynski
2020-02-02 20:04 ` Chris Murphy
2020-02-02 13:29 ` Martin Raiber
2020-02-02 13:36 ` Qu Wenruo
2020-02-02 14:14 ` Roman Mamedov
2020-02-02 14:45 ` Swâmi Petaramesh
2020-02-02 23:34 ` Zygo Blaxell
2020-02-03 6:28 ` Skibbi
2020-02-03 16:12 ` Chris Murphy
2020-02-03 19:01 ` Marc Joliet [this message]
2020-02-03 7:00 ` Swâmi Petaramesh
2020-02-02 19:56 ` Chris Murphy
2020-02-03 6:38 ` Skibbi
2020-02-03 6:51 ` Qu Wenruo
2020-02-03 8:42 ` Skibbi
2020-02-03 10:10 ` Qu Wenruo
2020-02-03 10:17 ` Qu Wenruo
2020-02-03 10:56 ` Skibbi
2020-02-03 11:09 ` Qu Wenruo
2020-02-03 16:17 ` Chris Murphy
2020-02-02 19:57 ` Chris Murphy
2020-02-03 19:14 ` Achim Gratz
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=2497374.lGaqSPkdTl@thetick \
--to=marcec@gmx.de \
--cc=linux-btrfs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.