From: Roman Mamedov <rm@romanrm.net>
To: Victor Banon <banon.victor@gmail.com>
Cc: remi@georgianit.com, linux-btrfs@vger.kernel.org
Subject: Re: BTRFS errors following bad SATA connection
Date: Sat, 4 Jan 2025 02:04:26 +0500 [thread overview]
Message-ID: <20250104020426.3899f4c8@nvm> (raw)
In-Reply-To: <2ff268f4-8565-45e1-b752-3ca85c736841@gmail.com>
On Fri, 3 Jan 2025 19:47:59 +0100
Victor Banon <banon.victor@gmail.com> wrote:
> My optimism was short-lived. I can't make meaningful progress deleting
> the files because the filesystem keeps going read-only (see attached
> log) soon after initiating a scan. This wasn't a problem before. I'm not
> sure what the standard procedure for bypassing this (rw remount after
> error is not allowed), so I've just been rebooting when this happens.
You mean a scan as suggested previously, trying to rename unreadable files to
"bad", or just a read-only pass too? It is probably way too broken after all,
so you might as well start planning backup+recreate.
> I'm also noticing that some files that resulted in i/o errors (when
> being cat'd to /dev/null) yesterday are fine today. And the other way
> around too: there seemingly are files that were fine yesterday but are
> bad today.
Not sure what to make of it, if you had mdadm raid1 underneath, this could
have been explained by differing mirror contents, and the randomness of which
one is used for reads today. With RAID5 data can differ when read from data
disks to when reconstructed from parity, but in a clean array there shouldn't
be any reconstruct reads.
> Thank you for the information. What does this mean in practice? Do I
> just ignore this file forever?
In a remote possibility if you could figure out all the other corruptions,
delete/replace all the affected files, and the only thing remaining would be a
small undeletable file somewhere, moving the containing directory away
somewhere and ignoring it for the time being could have been an option. But it
appears you are still a long way from that and might not reach that stage at
all.
> What about the corrupted files that are /not/ in my trash bin, can I never
> restore them either?
I believe you should be able to move or rename the directory they are in
freely (such as the trash bin itself), or at least one which is another level
above from that.
--
With respect,
Roman
next prev parent reply other threads:[~2025-01-03 21:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <9443ea9c-08dc-4d08-81a6-cb91940e791e@gmail.com>
2025-01-01 18:25 ` BTRFS errors following bad SATA connection Victor Banon
2025-01-01 23:40 ` remi
2025-01-02 9:32 ` Victor Banon
2025-01-02 13:33 ` Roman Mamedov
2025-01-02 13:40 ` Victor Banon
2025-01-03 8:21 ` Victor Banon
2025-01-03 12:09 ` Roman Mamedov
2025-01-03 12:42 ` Victor Banon
2025-01-03 13:45 ` Roman Mamedov
2025-01-03 18:47 ` Victor Banon
2025-01-03 21:04 ` Roman Mamedov [this message]
2025-01-03 21:24 ` Victor Banon
2025-01-04 13:57 ` Roman Mamedov
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=20250104020426.3899f4c8@nvm \
--to=rm@romanrm.net \
--cc=banon.victor@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=remi@georgianit.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