> There is one io error in the log below,
Apparently, that's not a real EIO. We need to fix it.
But can't be the root cause we are looking for here.
----
> Feb 24 22:41:59 home kernel: BTRFS: error (device dm-6) in
btrfs_run_delayed_refs:3076: errno=-5 IO failure
> Feb 24 22:41:59 home kernel: BTRFS info (device dm-6): forced readonly
static int run_delayed_extent_op(struct btrfs_trans_handle *trans,
struct btrfs_fs_info *fs_info,
struct btrfs_delayed_ref_head *head,
struct btrfs_delayed_extent_op *extent_op)
{
::
} else {
err = -EIO;
goto out;
}
----
> but other than that I have never had io errors before, or any other
troubles.
Hm. btrfs dev stat shows real disk IO errors.
As this FS isn't mountable .. pls try
btrfs dev stat <dev> > file
search for 'device stats', there will be one for each disk.
Or it reports in the syslog when it happens not necessarily
during dedupe.
> One of my other filesystems share the same two discs and it is still
fine, so I think the hardware is probably ok.
Right. I guess that too. A confirmation will be better.
> I've copied the beginning of the errors below.
At my end finding the root cause of 'parent transid verify failed'
during/after dedupe is is kind of fading as disk seems to be had
no issues. which I had in mind.
Also, there wasn't abrupt power-recycle here? I presume.
It's better to save the output disk1-log and disk2-log as below
before further efforts to recovery. Just in case if something
pops out.
btrfs in dump-super -fa disk1 > disk1-log
btrfs in dump-tree --degraded disk1 >> disk1-log [1]
btrfs in dump-super -fa disk2 > disk2-log
btrfs in dump-tree --degraded disk2 >> disk2-log [1]
[1]
--degraded option is in the ML.
[PATCH] btrfs-progs: dump-tree: add degraded option
Thanks, Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
