On Wed, May 03, 2017 at 11:32:26AM +0500, Roman Mamedov wrote:
> > Actually, another thought:
> > Is there or should there be a way to repair around the bit that cannot
> > be repaired?
> > Separately, or not, can I locate which bits are causing the repair to
> > fail and maybe get a pointer to the
On Tue, 2 May 2017 23:17:11 -0700
Marc MERLIN wrote:
> On Tue, May 02, 2017 at 11:00:08PM -0700, Marc MERLIN wrote:
> > David,
> >
> > I think you maintain btrfs-progs, but I'm not sure if you're in charge
> > of check --repair.
> > Could you comment on the bottom of the mail, namely:
> > > fai
On Tue, May 02, 2017 at 11:00:08PM -0700, Marc MERLIN wrote:
> David,
>
> I think you maintain btrfs-progs, but I'm not sure if you're in charge
> of check --repair.
> Could you comment on the bottom of the mail, namely:
> > failed to repair damaged filesystem, aborting
> > So, I'm out of luck no
David,
I think you maintain btrfs-progs, but I'm not sure if you're in charge
of check --repair.
Could you comment on the bottom of the mail, namely:
> failed to repair damaged filesystem, aborting
> So, I'm out of luck now, full wipe and 3-5 day rebuild?
Thanks,
Marc
Rest:
On Tue, May 02, 201
(cc trimmed)
The one in debian/unstable crashed:
gargamel:~# btrfs --version
btrfs-progs v4.7.3
gargamel:~# btrfs check --repair /dev/mapper/dshelf2
bytenr mismatch, want=2899180224512, have=3981076597540270796
extent-tree.c:2721: alloc_reserved_tree_block: Assertion `ret` failed.
btrfs[0x43e418]