linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Henk Slager <eye1tm@gmail.com>
To: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
Cc: Francesco Turco <fturco@fastmail.fm>,
	Chris Murphy <lists@colorremedies.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Frequent btrfs corruption on a USB flash drive
Date: Fri, 8 Jul 2016 20:16:11 +0200	[thread overview]
Message-ID: <CAPmG0japRHX7_BBAHGAh=uwPTOOYDvAcAXmvT60VGabYHsr2iw@mail.gmail.com> (raw)
In-Reply-To: <8cfbbe33-86da-7199-1b4e-cf13fa8e0f1b@gmail.com>

>> Device is GOOD
>>
>> I also created a big file with dd using /dev/urandom with the same size
>> as my flash drive, copied it once and read it three times. The SHA-1
>> checksum is always the same and matches the original one on the hard disk.
>>
>> So after much testing I feel I can conclude that my USB flash drive is
>> not fake and it is not defective.
>>
> For what it's worth, there's multiple other things that could cause similar
> issues.  I've had a number of cases where bad USB hubs or poorly designed
> (or just buggy or failing) USB controllers caused similar data corruption,
> the most recent one being an issue with both a bad USB 2.0 hub (which did
> not properly implement the USB standard, counterfeit USB devices come in all
> types) and a malfunctioning USB 3.0 controller (which did not properly
> account for things that didn't properly implement the standard and had no
> recovery code to handle this in the drivers).  I ended up in most cases
> checking the ports using other USB devices (at least a keyboard, a mouse,
> and a USB serial adapter).

Similar as Austin, I also want to note that there might be USB related
issues that only pop-up after some time and not in tests.

For example, this weekend I connected a 2.5inch 500G drive with its
Y-cable to a H87M-Pro board that is fed by a 80+Gold PSU, despite its
many 'bad sectors' I remembered from 2 years ago in a btrfs raid1
setup. This 500G disk has worked well for almost 2 years connected to
a 7-inch eeepc4G, XFS formatted. But with the H87M-Pro I just now saw
that it dropped off the USB every now and then, causing trouble for
Btrfs.

For connecting harddisks to phones, I once bought an external powered
hub, and I put that between the board the the 500G disk => that made
it all stable, no disconnects and Btrfs works fine as expected. I had
similar issues on another PC with a Sandisk Extreme 64G USB3 stick,
but that was likely a protocol issue.

So maybe try to use the stick with your use case in another HW setup,
hopefully then it is stable for a longer time than the few days now.

  reply	other threads:[~2016-07-08 18:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-07 13:49 Frequent btrfs corruption on a USB flash drive Francesco Turco
2016-07-07 14:27 ` Austin S. Hemmelgarn
2016-07-07 14:55   ` Francesco Turco
2016-07-07 15:42     ` Austin S. Hemmelgarn
2016-07-07 18:25     ` Chris Murphy
2016-07-07 18:41       ` Francesco Turco
2016-07-07 17:57 ` Chris Murphy
2016-07-08 16:10   ` Francesco Turco
2016-07-08 16:53     ` Austin S. Hemmelgarn
2016-07-08 18:16       ` Henk Slager [this message]
2016-07-07 21:11 ` Andrew E. Mileski
2016-07-07 21:13   ` Francesco Turco
2016-07-07 22:38     ` Andrew E. Mileski
2016-07-07 23:07       ` Chris Murphy

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='CAPmG0japRHX7_BBAHGAh=uwPTOOYDvAcAXmvT60VGabYHsr2iw@mail.gmail.com' \
    --to=eye1tm@gmail.com \
    --cc=ahferroin7@gmail.com \
    --cc=fturco@fastmail.fm \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.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 NNTP newsgroup(s).