All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: Russell Coker <russell@coker.com.au>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: btrfs dev sta not updating
Date: Tue, 23 Jun 2020 14:13:04 +0300	[thread overview]
Message-ID: <00ce925f-e8bb-be84-40bb-25fd215891e6@suse.com> (raw)
In-Reply-To: <6248217.VoG1EAXHid@liv>



On 23.06.20 г. 12:48 ч., Russell Coker wrote:
> On Tuesday, 23 June 2020 6:17:00 PM AEST Nikolay Borisov wrote:
>>> In this case I'm getting application IO errors and lost data, so if the
>>> error count is designed to not count recovered errors then it's still not
>>> doing the right thing.
>>
>> In this case yes, however this was utterly not clear from your initial
>> email. In fact it seems you have omitted quite a lot of information. So
>> let's step back and start afresh. So first give information about your
>> current btrfs setup by giving the output of:
>>
>> btrfs fi usage /path/to/btrfs
> 
> # btrfs fi usa .
> Overall:
>     Device size:                  62.50GiB
>     Device allocated:             19.02GiB
>     Device unallocated:           43.48GiB
>     Device missing:                  0.00B
>     Used:                         16.26GiB
>     Free (estimated):             44.25GiB      (min: 22.51GiB)
>     Data ratio:                       1.00
>     Metadata ratio:                   2.00
>     Global reserve:               17.06MiB      (used: 0.00B)
> 
> Data,single: Size:17.01GiB, Used:16.23GiB (95.43%)
>    /dev/sdc1      17.01GiB
> 
> Metadata,DUP: Size:1.00GiB, Used:17.19MiB (1.68%)
>    /dev/sdc1       2.00GiB
> 
> System,DUP: Size:8.00MiB, Used:16.00KiB (0.20%)
>    /dev/sdc1      16.00MiB
> 
> Unallocated:
>    /dev/sdc1      43.48GiB

Do you use compression on this filesystem i.e have you mounted with
-ocompression= option ?

Based on this data alone it's evident that you don't really have mirrors
of the data, in this case having experienced the checksum errors should
have indeed resulted in error counters being incremented. I'll look into
this.

<snip>

  reply	other threads:[~2020-06-23 11:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-23  2:09 btrfs dev sta not updating Russell Coker
2020-06-23  6:03 ` Nikolay Borisov
2020-06-23  6:17   ` waxhead
2020-06-23  7:11     ` Nikolay Borisov
2020-06-23  8:00   ` Russell Coker
2020-06-23  8:17     ` Nikolay Borisov
2020-06-23  9:48       ` Russell Coker
2020-06-23 11:13         ` Nikolay Borisov [this message]
2020-06-23 11:21           ` Russell Coker
2020-06-24 11:39           ` Zygo Blaxell
2020-06-24 13:04             ` Nikolay Borisov

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=00ce925f-e8bb-be84-40bb-25fd215891e6@suse.com \
    --to=nborisov@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=russell@coker.com.au \
    /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.