On Wed, Jan 08, 2020 at 11:42:05AM +0000, Filipe Manana wrote: > > > > Should these patches be marked for stable (5.0+, but see below for > > > > caveats about 5.0)? The bug affects 5.3 and 5.4 which are still active, > > > > and dedupe is an important feature for some users. > > > > > > Usually I only mark things for stable that are critical: corruptions, > > > crashes and memory leaks for example. > > > I don't think this is a critical issue, since none of those things > > > happen. It's certainly inconvenient to not have > > > an extent fully deduplicated, but it's just that. > > > > In btrfs the reference counting is done by extent and extents are > > immutable, so extents are either fully deduplicated, or not deduplicated > > at all. We have to dedupe every part of an extent, and if we fail to > > do so, no data space is saved while metadata usage increases for the > > new partial extent reference. > > Yes, I know. That was explained in the cover letter, why allowing > deduplication of the eof block is more important for btrfs than it is > for xfs for example. > > > > > This bug means the dedupe feature is not usable _at all_ for single-extent > > files with non-aligned EOF, and that is a significant problem for users > > that rely on dedupe to manage space usage on btrfs (e.g. for build > > servers where there are millions of duplicate odd-sized small files, and > > the space savings from working dedupe can be 90% or more). Doubling or > > tripling space usage for the same data is beyond inconvenience. > > Sure, I understand that, I know how btrfs manages extents and I'm well > familiar with its cloning/deduplication implementation. > > Still, it's not something I consider critical enough to get to stable, > as there's no corruption, data loss or a crash. > That doesn't mean the patches aren't going to stable branches, that > depends on the maintainers of each subsystem (vfs, btrfs). To me this looks like a usability bug and regression so I'm all for adding it to stable. Less serious fixes than corruption, data loss and crash land in stable kernels anyway, so if this fixes behaviour and usecases then it qualifies. I evaluate each patch for stable inclusion so the CC: stable is not required to be in the patch itself when posted, and late requests for inclusion to stable have been working well so we have the process in place.
