[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#910074: linux-image-4.9.0-8-amd64: BTRFS data loss - kernel BUG at .../linux-4.9.110/fs/btrfs/ctree.c:3178



Hi Hans,

On Wed, Oct 03, 2018 at 12:05:31AM +0200, Hans van Kranenburg wrote:
> Hi,
> 
> On 10/02/2018 10:08 PM, Nicholas D Steeves wrote:
> > Hi Michael,
> > 
> > On Tue, Oct 02, 2018 at 11:37:45AM +0100, Michael Firth wrote:
> >>
> >> BTRFS may not be a filesystem that everyone uses, but I feel if it is in
> >> the Debian kernel then bugs that can cause data loss should be fixed if
> >> a patch already exists.
> > 
> > In principle I agree; although I think it would be safer to coordinate
> > with Greg Kroah-Harman about getting them applied upstream before
> > importing them into Debian, since (afaik)
> 
> > we don't have any btrfs
> > specialists working on our kernel...people who would know if importing
> > one of these patches will introduce unintended side-effects or a
> > rabbit hole of patches.
> 
> This is not a debian specific issue. The upstream btrfs team does not
> have enough work capacity to do this, and mainly focuses on going
> forward instead of looking back. And I don't think there's really
> someone who would know the things mentioned above except for the authors
> of the patches themselves (who tag them for stable if it's data
> corruption and if they know it will work (tm)), or the btrfs maintainer
> who knows which ones to put together in which order to prepare the next
> kernel release.

Agreed!  Also, acknowledging when issues aren't Debian-specific and
then working with upstream so everyone can benefit is one reason we
have a great reputation for giving back to the larger community :-)

> 
> >  Maybe it would be safer to look at the delta
> > between btrfs in 4.9.x and 4.14.x and ask for backported fixes from
> > 4.14.x to 4.9.x? (eg: more than six months of testing in 4.14.x, like
> > the -o ssd bug that is still present in 4.9.x)
> 
> For the -o ssd issue, in hindsight, it was a mistake to not get that
> into 4.9 earlier.
> 
> Every user who wants to try out btrfs on his/her computer with Stretch
> and uses it as the root filesystem on a disk which is not too large is
> still affected by this sub-optimal behaviour.
> 
> So I guess that's a TODO for me, to still get it done now. It's 951e7966
> and 583b723151 with a few small changes to make it apply. At least it
> has had enough testing, and the amount of users with out-of-space
> filesystems has decreased notably in the last year in #btrfs IRC. :)

Thank you!  I updated our wiki page within a week of learning about
the patch, but in the future would you prefer if I file a bug?  I
don't imagine it will be more than two bugs a year ;-)  Btw, would you
please forward the bug to me for the 951e7966 and 583b723151 backport?

Sincerely,
Nicholas

Attachment: signature.asc
Description: PGP signature


Reply to: