linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Francesco Turco <fturco@fastmail.fm>
To: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: Frequent btrfs corruption on a USB flash drive
Date: Thu, 7 Jul 2016 16:55:18 +0200	[thread overview]
Message-ID: <eefaeb0f-9eb0-bd2c-3ce5-5eb28bb43c68@fastmail.fm> (raw)
In-Reply-To: <87efcca5-6871-2dde-e2df-40602f1a24c2@gmail.com>

On 2016-07-07 16:27, Austin S. Hemmelgarn wrote:
> This seems odd, are you trying to access anything over NFS or some other
> network filesystem protocol here?  If not, then I believe you've found a
> bug, because I'm pretty certain we shouldn't be returning -ESTALE for
> anything.

No, I don't use NFS or any other network filesystem.

> The question here is: Do you get any data corruption when using ext4?
> Quite often when there's a hardware issue, you won't see _any_
> indication of it other than corrupted files when using something like
> ext4 or XFS, but it will show up almost immediately with BTRFS because
> we validate checksums on almost everything.  There have been at least a
> couple of times I've found disk issues while converting from ext4 to
> BTRFS that I didn't know existed before, and then going back was able to
> reliable reproduce using other tools.
> 
> Also, FWIW, badblocks is not necessarily a reliable test method for
> flash drives, they often handle serialized reads like badblocks does
> very well even when failing.

I'm not sure. Commands don't fail explicitely when I use ext4, but I
agree with you that I may get corruption silently nonetheless. Perhaps I
should try to rule out an hardware problem by filling my USB flash drive
with a large random file and then checking if its SHA-1 checksum
corresponds to the original copy on the hard disk. But first I probably
should backup the current Btrfs filesystem with the dd command. Can I
proceed?

> Just to clarify, you're using BTRFS on top of disk encryption (LUKS? Or
> is it just raw encryption, or even something completely different?), on
> a USB flash drive (not a USB to SATA adapter with an SSD or HDD in it),
> correct?

I'm using a btrfs filesystem on a GUID partition encrypted with LUKS.
It's a Kingston USB flash drive connected directly to my desktop machine
via USB. It's definitively not a SSD or a HDD, and I'm not using any
adapter.

-- 
Website: http://www.fturco.net/
GPG key: 6712 2364 B2FE 30E1 4791 EB82 7BB1 1F53 29DE CD34

  reply	other threads:[~2016-07-07 14:55 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 [this message]
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
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=eefaeb0f-9eb0-bd2c-3ce5-5eb28bb43c68@fastmail.fm \
    --to=fturco@fastmail.fm \
    --cc=ahferroin7@gmail.com \
    --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 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).