btrfs check --repair question

btrfs check --repair question

[Tim Walberg]

All -

I have a file system I'm having some issues with. The initial symptoms were that mount
would run for several hours, either committing or rolling back transactions (primarily
due to a balance that was running when the system was rebooted for other reasons -
the skip_balance mount option was specified because of this), but would then be killed
due to an OOM condition (not much else running on the box at the time - a desktop system
where everything else was waiting for the mount to finish). That's the background. Kernel
4.8.1 - custom config, but otherwise stock kernel - and btrfs-tools 4.8.3.

Ran btrfs check, and the only thing it reports is a sequence of these:

ref mismatch on [5400814960640 16384] extent item 0, found 1
Backref 5400814960640 parent 5401010913280 root 5401010913280 not found in extent tree
backpointer mismatch on [5400814960640 16384]
owner ref check failed [5400814960640 16384]

Which, to my reading are simply some missing backrefs, and probably should be one of the
easier issues to correct, but I know --repair is still considered experimental/dangerous,
so I thought I'd ask before I run it... Is this a case that --repair can be reasonably
expected to handle, or would I be better off recreating the file system and restoring from
either my saved btrfs send archives or the more reliable backups?


		      tw



-- 
twalberg@gmail.com

Re: btrfs check --repair question

[Chris Murphy]

On Mon, Dec 12, 2016 at 5:19 AM, Tim Walberg <twalberg@comcast.net> wrote:
> All -
>
> I have a file system I'm having some issues with. The initial symptoms were that mount
> would run for several hours, either committing or rolling back transactions (primarily
> due to a balance that was running when the system was rebooted for other reasons -
> the skip_balance mount option was specified because of this), but would then be killed
> due to an OOM condition (not much else running on the box at the time - a desktop system
> where everything else was waiting for the mount to finish). That's the background. Kernel
> 4.8.1 - custom config, but otherwise stock kernel - and btrfs-tools 4.8.3.

There were some OOM related issues early in 4.8, I would try 4.8.12 or
even 4.8.14.


>
> Ran btrfs check, and the only thing it reports is a sequence of these:
>
> ref mismatch on [5400814960640 16384] extent item 0, found 1
> Backref 5400814960640 parent 5401010913280 root 5401010913280 not found in extent tree
> backpointer mismatch on [5400814960640 16384]
> owner ref check failed [5400814960640 16384]
>
> Which, to my reading are simply some missing backrefs, and probably should be one of the
> easier issues to correct, but I know --repair is still considered experimental/dangerous,
> so I thought I'd ask before I run it... Is this a case that --repair can be reasonably
> expected to handle, or would I be better off recreating the file system and restoring from
> either my saved btrfs send archives or the more reliable backups?

It might be that usebackuproot,ro mount will happen faster, and you
can update the backups. Then use --repair. It's still listed as
dangerous but it's gotten quite a bit less dangerous in later
versions.


-- 
Chris Murphy

btrfs check --repair question

[bepi]

Hi.


I had two cases of 'ref mismatch on extents .... ..', like you.

Any attempt at recovery has much worsened the problem.

I suggest you save importanto data and delete and recreate the partition.

I always have a partition for re-install from scratch, so that I can recover
data from damaged file system, without being forced to try to repair it.


Gdb

----------------------------------------------------
This mail has been sent using Alpikom webmail system
http://www.alpikom.it