Ah. Thank you for the replies. I didn't get them as mails and spinics
didn't update the thread until yesterday.
So I take it that the recommended course of action is not to wait for
any more or less unlikely btrfs-progs fix, but to try --repair and be
ready to restore from backup, too. Darn, and that over what probably
doesn't amount to more than a few dozen KB. Wish I could simply replace
the single subvolume instead, but I suppose that's one of btrfs's drawbacks.
I did a full partition backup some three weeks ago, so I'll have to
spend some hours to figure out what has changed since then, and how to
do incremental backups of it to different devices for the next time…
I don't have the time atm though; it'll probably take at least a week
(unless the partition decides to die) to report back.
As a side note, there was an ostensibly similar issue fixed in 2012:
https://bugzilla.novell.com/show_bug.cgi?id=760279 Guess that was a
different underlying issue, though.
Duncan posted on Wed, 23 Apr 2014 02:55:36 +0000:
> Andreas Reis posted on Tue, 22 Apr 2014 20:16:13 +0200 as excerpted:
>
> > Same failure with btrfs-progs from integration-20140421 (apart from
> > the line number 1156).
> >
> > Can I get a bit of input on this? Is it safe to just ignore the
> > error for now (as I'm doing atm), ie. remount as rw to skip the
> > orphan cleanup?
>
> I explained orphans in my other reply. Since they're simply not yet
> completed file deletions, it should be /relatively/ safe to continue
> ignoring and doing the manual remount rw, since that continues to
> kwork.
--
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
