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 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.