From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Francesco Turco <fturco@fastmail.fm>,
Chris Murphy <lists@colorremedies.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Frequent btrfs corruption on a USB flash drive
Date: Fri, 8 Jul 2016 12:53:32 -0400 [thread overview]
Message-ID: <8cfbbe33-86da-7199-1b4e-cf13fa8e0f1b@gmail.com> (raw)
In-Reply-To: <c8c5564e-623a-f1ca-b1c2-521e18de714c@fastmail.fm>
On 2016-07-08 12:10, Francesco Turco wrote:
> On 2016-07-07 19:57, Chris Murphy wrote:
>> Use F3 to test flash:
>> http://oss.digirati.com.br/f3/
>
> I tested my USB flash drive with F3 as you suggested, and there's no
> indication it is a fake device.
>
> ---------------
>
> # f3probe --destructive /dev/sdb
> F3 probe 6.0
> Copyright (C) 2010 Digirati Internet LTDA.
> This is free software; see the source for copying conditions.
>
> WARNING: Probing normally takes from a few seconds to 15 minutes, but
> it can take longer. Please be patient.
>
> Good news: The device `/dev/sdb' is the real thing
>
> Device geometry:
> *Usable* size: 57.69 GB (120979456 blocks)
> Announced size: 57.69 GB (120979456 blocks)
> Module: 64.00 GB (2^36 Bytes)
> Approximate cache size: 0.00 Byte (0 blocks), need-reset=no
> Physical block size: 512.00 Byte (2^9 Bytes)
>
> Probe time: 2'23"
>
> --------------
>
> $ f3read /run/media/fturco/a7d8a7b1-e0c2-4fbb-879f-e17046989f3c
> SECTORS ok/corrupted/changed/overwritten
> Validating file 1.h2w ... 2097152/ 0/ 0/ 0
> Validating file 2.h2w ... 2097152/ 0/ 0/ 0
> Validating file 3.h2w ... 2097152/ 0/ 0/ 0
> Validating file 4.h2w ... 2097152/ 0/ 0/ 0
> Validating file 5.h2w ... 2097152/ 0/ 0/ 0
> Validating file 6.h2w ... 2097152/ 0/ 0/ 0
> Validating file 7.h2w ... 2097152/ 0/ 0/ 0
> Validating file 8.h2w ... 2097152/ 0/ 0/ 0
> Validating file 9.h2w ... 2097152/ 0/ 0/ 0
> Validating file 10.h2w ... 2097152/ 0/ 0/ 0
> Validating file 11.h2w ... 2097152/ 0/ 0/ 0
> Validating file 12.h2w ... 2097152/ 0/ 0/ 0
> Validating file 13.h2w ... 2097152/ 0/ 0/ 0
> Validating file 14.h2w ... 2097152/ 0/ 0/ 0
> Validating file 15.h2w ... 2097152/ 0/ 0/ 0
> Validating file 16.h2w ... 2097152/ 0/ 0/ 0
> Validating file 17.h2w ... 2097152/ 0/ 0/ 0
> Validating file 18.h2w ... 2097152/ 0/ 0/ 0
> Validating file 19.h2w ... 2097152/ 0/ 0/ 0
> Validating file 20.h2w ... 2097152/ 0/ 0/ 0
> Validating file 21.h2w ... 2097152/ 0/ 0/ 0
> Validating file 22.h2w ... 2097152/ 0/ 0/ 0
> Validating file 23.h2w ... 2097152/ 0/ 0/ 0
> Validating file 24.h2w ... 2097152/ 0/ 0/ 0
> Validating file 25.h2w ... 2097152/ 0/ 0/ 0
> Validating file 26.h2w ... 2097152/ 0/ 0/ 0
> Validating file 27.h2w ... 2097152/ 0/ 0/ 0
> Validating file 28.h2w ... 2097152/ 0/ 0/ 0
> Validating file 29.h2w ... 2097152/ 0/ 0/ 0
> Validating file 30.h2w ... 2097152/ 0/ 0/ 0
> Validating file 31.h2w ... 2097152/ 0/ 0/ 0
> Validating file 32.h2w ... 2097152/ 0/ 0/ 0
> Validating file 33.h2w ... 2097152/ 0/ 0/ 0
> Validating file 34.h2w ... 2097152/ 0/ 0/ 0
> Validating file 35.h2w ... 2097152/ 0/ 0/ 0
> Validating file 36.h2w ... 2097152/ 0/ 0/ 0
> Validating file 37.h2w ... 2097152/ 0/ 0/ 0
> Validating file 38.h2w ... 2097152/ 0/ 0/ 0
> Validating file 39.h2w ... 2097152/ 0/ 0/ 0
> Validating file 40.h2w ... 2097152/ 0/ 0/ 0
> Validating file 41.h2w ... 2097152/ 0/ 0/ 0
> Validating file 42.h2w ... 2097152/ 0/ 0/ 0
> Validating file 43.h2w ... 2097152/ 0/ 0/ 0
> Validating file 44.h2w ... 2097152/ 0/ 0/ 0
> Validating file 45.h2w ... 2097152/ 0/ 0/ 0
> Validating file 46.h2w ... 2097152/ 0/ 0/ 0
> Validating file 47.h2w ... 2097152/ 0/ 0/ 0
> Validating file 48.h2w ... 2097152/ 0/ 0/ 0
> Validating file 49.h2w ... 2097152/ 0/ 0/ 0
> Validating file 50.h2w ... 2097152/ 0/ 0/ 0
> Validating file 51.h2w ... 2097152/ 0/ 0/ 0
> Validating file 52.h2w ... 2097152/ 0/ 0/ 0
> Validating file 53.h2w ... 2097152/ 0/ 0/ 0
> Validating file 54.h2w ... 2097152/ 0/ 0/ 0
> Validating file 55.h2w ... 2097152/ 0/ 0/ 0
> Validating file 56.h2w ... 1364266/ 0/ 0/ 0
>
> Data OK: 55.65 GB (116707626 sectors)
> Data LOST: 0.00 Byte (0 sectors)
> Corrupted: 0.00 Byte (0 sectors)
> Slightly changed: 0.00 Byte (0 sectors)
> Overwritten: 0.00 Byte (0 sectors)
> Average reading speed: 34.73 MB/s
>
> ----------------
>
>> Read more, and also includes a much faster alternative for GNOME:
>> https://blogs.gnome.org/hughsie/2015/01/28/detecting-fake-flash/
>
> I also tested my flash drive with gnome-multi-writer-probe, and it says
> it is not fake:
>
> # gnome-multi-writer-probe /dev/sdb
> 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).
next prev parent reply other threads:[~2016-07-08 16:53 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 [this message]
2016-07-08 18:16 ` Henk Slager
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=8cfbbe33-86da-7199-1b4e-cf13fa8e0f1b@gmail.com \
--to=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).