From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 References: <153923113649.5546.9840926895953408273.stgit@magnolia> <153923117420.5546.13317703807467393934.stgit@magnolia> <20181015003139.GZ6311@dastard> <20181102174229.GA4127@magnolia> In-Reply-To: <20181102174229.GA4127@magnolia> Reply-To: fdmanana@gmail.com From: Filipe Manana Date: Fri, 2 Nov 2018 18:18:45 +0000 Message-ID: Subject: Re: [PATCH 05/25] vfs: avoid problematic remapping requests into partial EOF block To: "Darrick J. Wong" Cc: Dave Chinner , Eric Sandeen , linux-nfs@vger.kernel.org, linux-cifs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-btrfs , linux-fsdevel , ocfs2-devel@oss.oracle.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: On Fri, Nov 2, 2018 at 5:42 PM Darrick J. Wong wr= ote: > > On Fri, Nov 02, 2018 at 12:04:39PM +0000, Filipe Manana wrote: > > On Mon, Oct 15, 2018 at 1:31 AM Dave Chinner wrot= e: > > > > > > On Fri, Oct 12, 2018 at 09:22:18PM +0100, Filipe Manana wrote: > > > > On Thu, Oct 11, 2018 at 5:13 AM Darrick J. Wong wrote: > > > > > > > > > > From: Darrick J. Wong > > > > > > > > > > A deduplication data corruption is exposed by fstests generic/505= on > > > > > XFS. > > > > > > > > (and btrfs) > > > > > > > > Btw, the generic test I wrote was indeed numbered 505, however it w= as > > > > never committed and there's now a generic/505 which has nothing to = do > > > > with deduplication. > > > > So you should update the changelog to avoid confusion. > > > > > > What test is it now? And if it hasn't been committed, are you going > > > to update it and repost as it clearly had value.... > > > > Sorry, I lost track of this. > > > > So what was the conclusion of the thread where discussion about this > > problem started? > > It wasn't clear to me if a consensus was reached and got lost on that > > long user space dedupe tools discussion between you and Zygo. > > > > The test assumed a fix of rounding down the range and deduping less > > bytes then requested (which ended up included in 4.19 for btrfs). > > > > From this vfs patch it seems it was decided to return errno -EDADE inst= ead. > > Is this the final decision? > > No, I reworked the whole mess to match btrfs-4.19 behavior of deduping > fewer bytes than requested. What about cloning? For cloning the issue is still not fixed in btrfs either. So was that done in a later version of this patchset or somewhere else? thanks > > --D > > > > > > > Cheers, > > > > > > Dave. > > > -- > > > Dave Chinner > > > david@fromorbit.com > > > > > > > > -- > > Filipe David Manana, > > > > =E2=80=9CWhether you think you can, or you think you can't =E2=80=94 yo= u're right.=E2=80=9D --=20 Filipe David Manana, =E2=80=9CWhether you think you can, or you think you can't =E2=80=94 you're= right.=E2=80=9D