All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell Coker <russell@coker.com.au>
To: linux-btrfs@vger.kernel.org, Qu Wenruo <quwenruo.btrfs@gmx.com>
Subject: Re: BTRFS error count 754 after reboot on Debian kernel 6.12.17
Date: Sun, 23 Mar 2025 15:11:35 +1100	[thread overview]
Message-ID: <2310073.iZASKD2KPV@xev> (raw)
In-Reply-To: <81b64f4f-59dc-4ca1-81de-2b77cf38cd3e@gmx.com>

On Sunday, 23 March 2025 08:36:56 AEDT Qu Wenruo wrote:
> > This is repeatable and it's 754 every time.
> > 
> > After I get the error I remove the device from the array and add it again.
> 
> How did you do the removal and add?

btrfs dev rem ...
btrfs dev add ...

> "btrfs device remove" then "btrfs device add"? Or just power the machine
> down and physically add/remove the device?

I didn't physically remove the devices because working out which device is 
which /dev/sd node is not easy at all.  For unrelated reasons the assignment 
of /dev/sd nodes is apparently random.

> > The system is a Dell PowerEdge T630.
> > 
> > The SSD could have a fault, but if so why does it only show up on reboot
> > and why 754 errors every time?
> 
> The error counters are stored inside the fs, it records all the history
> errors a device hit in the past.
> 
> You need to inform btrfs by either proper btrfs device removal/add, or
> make btrfs to zero the counters.

Yes I had done the proper device removal, but either the counters weren't 
properly reset or some other errors were occuring.  I even tried dding 1G of 
data from /dev/zero over the device after removal and that didn't help.

The problem has gone away now.  I was about to do another run to get dmesg 
output for you but accidentally removed the wrong device.  After I added that 
back then removed and re-added the correct device the problem went away.  I 
can now reboot without seeing an error count of 754.  I presume that forcing a 
bunch of metadata to be moved around changed things somehow.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/




  reply	other threads:[~2025-03-23  4:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-22 13:44 BTRFS error count 754 after reboot on Debian kernel 6.12.17 Russell Coker
2025-03-22 21:36 ` Qu Wenruo
2025-03-23  4:11   ` Russell Coker [this message]
2025-04-01  4:04 ` Chris Murphy
2025-04-01  5:18   ` Russell Coker
2025-04-01 16:00     ` Chris Murphy
2025-04-02  2:32       ` Russell Coker
2025-04-02  2:42         ` Chris Murphy
2025-04-02  5:01           ` Russell Coker

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=2310073.iZASKD2KPV@xev \
    --to=russell@coker.com.au \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.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.