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
--
[email protected]
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
