From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([198.137.202.9]:34431 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751905AbbKQKyi (ORCPT ); Tue, 17 Nov 2015 05:54:38 -0500 Date: Tue, 17 Nov 2015 02:54:33 -0800 From: Christoph Hellwig To: "Darrick J. Wong" Cc: Christoph Hellwig , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org Subject: Re: clone ioctl return values Message-ID: <20151117105433.GA18093@infradead.org> References: <20151116120431.GA2860@infradead.org> <20151117002822.GA32467@birch.djwong.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151117002822.GA32467@birch.djwong.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Nov 16, 2015 at 04:28:22PM -0800, Darrick J. Wong wrote: > > Try to reflink a device > > -XFS_IOC_CLONE_RANGE: Invalid argument > > +/mnt/test/test-157/dev1: No such device or address > > Huh. How did you get -ENODEV here? I ran this on 4.3 and got -EINVAL. This is current 4.4-rc. The error seems accidental I think. > Errrgh, the golden output of this test reflects the changes to the input > checking in Anna/Peng's copy_file_range/clone_file_range patches. > > So, I guess the question is, should I reset the golden output to whatever > btrfs spits out before that patchset, and we'll consider the alterations > to be bugs/regressions/whatever that ought to be fixed in their patches? Some bits in btrfs don't seem kosher. But it would be good to explicitly send patches for btrfs to adopt to what might make more sense, and then follow it in the other implementations.