btrfs check --repair question
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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs check --repair question
On Mon, Dec 12, 2016 at 5:19 AM, Tim Walberg 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
btrfs check --repair question
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 -- twalb...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
