On Mon, Jan 25, 2016 at 07:46:52PM +0000, Filipe Manana wrote:
> On Mon, Jan 25, 2016 at 3:55 PM, Marc MERLIN <marc@xxxxxxxxxxx> wrote:
> > I still have 2 more days before I can rebuild my broken filesystem.
> > In the meantime, I just got this new error with 4.4
>
> Nop, not new in 4.4. I have seen 1 report of someone hitting this with
> a 4.0 kernel in the past. Not a problem with send afaics but some
> inconsistent state achieved likely after adding/modifying/deleting a
> xattr.
>
> Nothing new, just send the output of btrfs-debug-tree -t <parent
> snapshot id> and for the send snapshot too. Also in the function that
> triggered the BUG_ON(), add a printk like the following right before
> the BUG_ON() line:
>
> if (sctx->cur_ino != sctx->cmp_key->objectid)
> printk(KERN_ERR "sctx->cur_ino = %llu, sctx->cmp_key->objectid =
> %llu\n", sctx->cmp_key->objectid, sctx->cmp_key->objectid);
>
> And see the result in dmesg/syslog.
Thanks for the reply.
I may not be able to reproduce this soon or at all because I'm about to
rebuild the damaged filesystem this happened on.
The point is that my filesystem is damaged, but this is not a reason to
crash the kernel and the machine.
Can this be changed to an abort and remount read only instead?
Thanks,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
--
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
