From unknown Wed Aug 20 04:11:25 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#5914 <5914@debbugs.gnu.org> To: bug#5914 <5914@debbugs.gnu.org> Subject: Status: feature request and non-bug patches submit policy Reply-To: bug#5914 <5914@debbugs.gnu.org> Date: Wed, 20 Aug 2025 11:11:25 +0000 retitle 5914 feature request and non-bug patches submit policy reassign 5914 coreutils submitter 5914 "jeff.liu" severity 5914 wishlist thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 09 08:38:45 2010 Received: (at submit) by debbugs.gnu.org; 9 Apr 2010 12:38:45 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0DTw-0006go-JS for submit@debbugs.gnu.org; Fri, 09 Apr 2010 08:38:44 -0400 Received: from mail.gnu.org ([199.232.76.166] helo=mx10.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0AVY-0004nj-LA for submit@debbugs.gnu.org; Fri, 09 Apr 2010 05:28:12 -0400 Received: from lists.gnu.org ([199.232.76.165]:53841) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1O0AVV-0008D4-M3 for submit@debbugs.gnu.org; Fri, 09 Apr 2010 05:28:09 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O0AVV-0004G8-3k for bug-coreutils@gnu.org; Fri, 09 Apr 2010 05:28:09 -0400 Received: from [140.186.70.92] (port=59505 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O0AVS-0004DG-UG for bug-coreutils@gnu.org; Fri, 09 Apr 2010 05:28:07 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O0AVR-0003LV-Mb for bug-coreutils@gnu.org; Fri, 09 Apr 2010 05:28:06 -0400 Received: from rcsinet12.oracle.com ([148.87.113.124]:37553) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0AVR-0003LI-Gh for bug-coreutils@gnu.org; Fri, 09 Apr 2010 05:28:05 -0400 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o399S3h2031098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 9 Apr 2010 09:28:04 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o398m6G0023884 for ; Fri, 9 Apr 2010 09:28:02 GMT Received: from abhmt018.oracle.com by acsmt355.oracle.com with ESMTP id 148456391270805279; Fri, 09 Apr 2010 02:27:59 -0700 Received: from [10.182.120.235] (/10.182.120.235) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Apr 2010 02:27:59 -0700 Message-ID: <4BBEF339.9060008@oracle.com> Date: Fri, 09 Apr 2010 17:28:25 +0800 From: "jeff.liu" User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: bug-coreutils@gnu.org Subject: feature request and non-bug patches submit policy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BBEF322.00C7:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -6.6 (------) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 09 Apr 2010 08:38:43 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) Hi Jim, I'd like to know if I should still submit new feature patches to here or coreutils@gnu.org. A few months ago, I found the heads up for the new coreutils@gnu.org mail list, and it mentioned only the bugs report/fix should be send to this list. Otherwise, for the general discussion and new features request should go to the new list, Am I right? But looks there is little activity in coreutils@gnu.org, I have sent a few patches related to cp(1) sparse file enhancement through fiemap ioctl(2), but almostly no response from the list members in about 2 weeks, except Joel I cc-ed. Maybe nobody is interesed. :( I know you guys are busy with work. Actually, I just want to know if I was misunderstood the policy? If so, I will submit the patches here. Sorry for the inconvience! Best regards, -Jeff From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 09 09:28:27 2010 Received: (at 5914) by debbugs.gnu.org; 9 Apr 2010 13:28:27 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0EG2-00071F-89 for submit@debbugs.gnu.org; Fri, 09 Apr 2010 09:28:27 -0400 Received: from smtp3-g21.free.fr ([212.27.42.3]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0EFz-00071A-Kk for 5914@debbugs.gnu.org; Fri, 09 Apr 2010 09:28:25 -0400 Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id E03C4818062; Fri, 9 Apr 2010 15:28:14 +0200 (CEST) Received: from mx.meyering.net (mx.meyering.net [82.230.74.64]) by smtp3-g21.free.fr (Postfix) with ESMTP id 0242C81805A; Fri, 9 Apr 2010 15:28:11 +0200 (CEST) Received: by rho.meyering.net (Acme Bit-Twister, from userid 1000) id D2F2C9DF; Fri, 9 Apr 2010 15:28:11 +0200 (CEST) From: Jim Meyering To: "jeff.liu" Subject: Re: bug#5914: feature request and non-bug patches submit policy In-Reply-To: <4BBEF339.9060008@oracle.com> (jeff liu's message of "Fri, 09 Apr 2010 17:28:25 +0800") References: <4BBEF339.9060008@oracle.com> Date: Fri, 09 Apr 2010 15:28:11 +0200 Message-ID: <87ochs4uxg.fsf@meyering.net> Lines: 53 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 5914 Cc: 5914@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.9 (--) jeff.liu wrote: > Hi Jim, > > I'd like to know if I should still submit new feature patches to here or coreutils@gnu.org. > > A few months ago, I found the heads up for the new coreutils@gnu.org mail list, and it mentioned > only the bugs report/fix should be send to this list. Otherwise, for the general discussion and new > features request should go to the new list, Am I right? > > But looks there is little activity in coreutils@gnu.org, I have sent a few patches related to cp(1) > sparse file enhancement through fiemap ioctl(2), but almostly no response from the list members in > about 2 weeks, except Joel I cc-ed. Maybe nobody is interesed. :( > > I know you guys are busy with work. Actually, I just want to know if I was misunderstood the > policy? If so, I will submit the patches here. Hi Jeff, bug-coreutils is definitely the right list, and I confirmed this morning that you are covered on the copyright front (Oracle has an "ANY" assignment with the FSF), assuming you're doing this on company time. If you're doing any of this work on your own time, you should follow the procedure outlined here: http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING#n327 Over the last few weeks I've been working on other projects (pretty must time dedicated to getting grep back into shape), so coreutils has languished. Sorry for not giving more feedback, but I have been watching. In fact, seeing the use of HAVE_FTRUNCATE that is moved by your patch is what prompted me to mark the ftruncate module as obsolete and remove that code from copy.c. While I'm writing, here's one high-level question for you. When would your new --fiemap-sync option be useful, and what change in semantics will I see between when I use it and when I don't? --fiemap-sync sync file data before fiemap\n\ I cannot deduce that from anything I've seen written in your patch or even in the related kernel sources I've seen so far. I.e., if you can justify the addition of this option, then that justification should be obvious from its description in doc/coreutils.texi. Sure, I know what "sync" means, but for a command-line tool like cp, why provide the option when the user can simply precede the cp invocation with a use of sync(1). I presume you can give an example where cp produces different results with and without --fiemap-sync. Please demonstrate that. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 09 10:04:41 2010 Received: (at 5914) by debbugs.gnu.org; 9 Apr 2010 14:04:41 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0Ep7-0007HT-Da for submit@debbugs.gnu.org; Fri, 09 Apr 2010 10:04:41 -0400 Received: from mail1.slb.deg.dub.stisp.net ([84.203.253.98]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1O0Ep5-0007HK-4D for 5914@debbugs.gnu.org; Fri, 09 Apr 2010 10:04:40 -0400 Received: (qmail 63939 invoked from network); 9 Apr 2010 14:04:33 -0000 Received: from unknown (HELO ?192.168.2.25?) (84.203.137.218) by mail1.slb.deg.dub.stisp.net with SMTP; 9 Apr 2010 14:04:33 -0000 Message-ID: <4BBF33E7.5020908@draigBrady.com> Date: Fri, 09 Apr 2010 15:04:23 +0100 From: =?ISO-8859-1?Q?P=E1draig_Brady?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "jeff.liu" Subject: Re: bug#5914: feature request and non-bug patches submit policy References: <4BBEF339.9060008@oracle.com> In-Reply-To: <4BBEF339.9060008@oracle.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 5914 Cc: 5914@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.1 (---) On 09/04/10 10:28, jeff.liu wrote: > Hi Jim, > > I'd like to know if I should still submit new feature patches to here or coreutils@gnu.org. > > A few months ago, I found the heads up for the new coreutils@gnu.org mail list, and it mentioned > only the bugs report/fix should be send to this list. Otherwise, for the general discussion and new > features request should go to the new list, Am I right? > > But looks there is little activity in coreutils@gnu.org, I have sent a few patches related to cp(1) > sparse file enhancement through fiemap ioctl(2), but almostly no response from the list members in > about 2 weeks, except Joel I cc-ed. Maybe nobody is interesed. :( > > I know you guys are busy with work. Actually, I just want to know if I was misunderstood the > policy? If so, I will submit the patches here. > > Sorry for the inconvience! Oops! I was sure I had subscribed to that new list. I've done so again in any case. Patches should still go to bug-coreutils@gnu.org BTW. I'm just catching up on work after holidays, but a quick note Re: `cp --reflink` We were trying to come up with a generic term for the CoW feature. For BTRFS, `cp` currently needs to copy attributes explicitly, but for OCFS2 we can just do the reflink and not bother with all the attribute copying. The interface is fine as is I think. If there is a generic interface for CoW in future, we can use that. cheers, Pádraig. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 09 11:40:16 2010 Received: (at 5914) by debbugs.gnu.org; 9 Apr 2010 15:40:16 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0GJb-000808-NI for submit@debbugs.gnu.org; Fri, 09 Apr 2010 11:40:16 -0400 Received: from rcsinet11.oracle.com ([148.87.113.123]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0Fty-0007nt-1r for 5914@debbugs.gnu.org; Fri, 09 Apr 2010 11:13:46 -0400 Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o39FDcAh005823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Apr 2010 15:13:40 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o39BKj3l007317; Fri, 9 Apr 2010 15:13:36 GMT Received: from abhmt004.oracle.com by acsmt354.oracle.com with ESMTP id 149258551270825911; Fri, 09 Apr 2010 08:11:51 -0700 Received: from [123.119.96.226] (/123.119.96.226) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Apr 2010 08:11:51 -0700 Message-ID: <4BBF43D1.3030403@oracle.com> Date: Fri, 09 Apr 2010 23:12:17 +0800 From: "jeff.liu" User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Jim Meyering Subject: Re: bug#5914: feature request and non-bug patches submit policy References: <4BBEF339.9060008@oracle.com> <87ochs4uxg.fsf@meyering.net> In-Reply-To: <87ochs4uxg.fsf@meyering.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BBF4421.010F:SCFMA4539814,ss=1,fgs=0 X-Spam-Score: -6.6 (------) X-Debbugs-Envelope-To: 5914 X-Mailman-Approved-At: Fri, 09 Apr 2010 11:40:15 -0400 Cc: Sunil Mushran , 5914@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) Hi Jim, Thanks for your prompt response! Jim Meyering wrote: > jeff.liu wrote: >> Hi Jim, >> >> I'd like to know if I should still submit new feature patches to here or coreutils@gnu.org. >> >> A few months ago, I found the heads up for the new coreutils@gnu.org mail list, and it mentioned >> only the bugs report/fix should be send to this list. Otherwise, for the general discussion and new >> features request should go to the new list, Am I right? >> >> But looks there is little activity in coreutils@gnu.org, I have sent a few patches related to cp(1) >> sparse file enhancement through fiemap ioctl(2), but almostly no response from the list members in >> about 2 weeks, except Joel I cc-ed. Maybe nobody is interesed. :( >> >> I know you guys are busy with work. Actually, I just want to know if I was misunderstood the >> policy? If so, I will submit the patches here. > > Hi Jeff, > > bug-coreutils is definitely the right list, and I confirmed this > morning that you are covered on the copyright front (Oracle has an "ANY" > assignment with the FSF), assuming you're doing this on company time. > If you're doing any of this work on your own time, you should follow > the procedure outlined here: > > http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING#n327 > Yeah, I did this work on my company time. > Over the last few weeks I've been working on other projects > (pretty must time dedicated to getting grep back into shape), > so coreutils has languished. Sorry for not giving more feedback, > but I have been watching. > > In fact, seeing the use of HAVE_FTRUNCATE that is moved by your patch > is what prompted me to mark the ftruncate module as obsolete and remove > that code from copy.c. > > While I'm writing, here's one high-level question for you. > When would your new --fiemap-sync option be useful, and what change > in semantics will I see between when I use it and when I don't? > > --fiemap-sync sync file data before fiemap\n\ > IMHO, there is no difference from the user's point of view with or without this option. and on the kernel side, if FIEMAP_FLAG_SYNC was specified, it just do the dirty page process regardless of the sync succeeds or failed due to ENOSPC or EIO or other errors. I need to do more investigation to answer this question. > I cannot deduce that from anything I've seen written in your > patch or even in the related kernel sources I've seen so far. > I.e., if you can justify the addition of this option, > then that justification should be obvious from its description > in doc/coreutils.texi. > > Sure, I know what "sync" means, but for a command-line tool > like cp, why provide the option when the user can simply > precede the cp invocation with a use of sync(1). > At first, I think the user could just run `cp --fiemap=[WHEN] --fiemap-sync' in terms of 'sync; cp...' semantics. But actually, just as you said, it is indeed a duplicate option since we can do same thing in a simply way. > I presume you can give an example where cp produces different results > with and without --fiemap-sync. Please demonstrate that. I will try to do more test for the verify check. Best Regards, -Jeff From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 09 12:00:06 2010 Received: (at 5914) by debbugs.gnu.org; 9 Apr 2010 16:00:06 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0Gcn-00088q-OF for submit@debbugs.gnu.org; Fri, 09 Apr 2010 12:00:05 -0400 Received: from acsinet12.oracle.com ([141.146.126.234]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0Gcm-00088B-AG for 5914@debbugs.gnu.org; Fri, 09 Apr 2010 12:00:04 -0400 Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o39FxvSH015337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Apr 2010 15:59:58 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o39FxrPc012506; Fri, 9 Apr 2010 15:59:53 GMT Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 161946361270828785; Fri, 09 Apr 2010 08:59:45 -0700 Received: from [123.119.96.226] (/123.119.96.226) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Apr 2010 08:59:44 -0700 Message-ID: <4BBF4F0A.1090608@oracle.com> Date: Sat, 10 Apr 2010 00:00:10 +0800 From: "jeff.liu" User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: =?ISO-8859-1?Q?P=E1draig_Brady?= Subject: Re: bug#5914: feature request and non-bug patches submit policy References: <4BBEF339.9060008@oracle.com> <4BBF33E7.5020908@draigBrady.com> In-Reply-To: <4BBF33E7.5020908@draigBrady.com> Content-Type: text/plain; charset=ISO-8859-1 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BBF4EFC.0137:SCFMA4539814,ss=1,fgs=0 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by acsinet12.oracle.com id o39FxvSH015337 X-Spam-Score: -6.6 (------) X-Debbugs-Envelope-To: 5914 Cc: Sunil Mushran , 5914@debbugs.gnu.org, Joel Becker , Tao Ma X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) P=E1draig Brady wrote: > On 09/04/10 10:28, jeff.liu wrote: >> Hi Jim, >> >> I'd like to know if I should still submit new feature patches to here = or coreutils@gnu.org. >> >> A few months ago, I found the heads up for the new coreutils@gnu.org m= ail list, and it mentioned >> only the bugs report/fix should be send to this list. Otherwise, for = the general discussion and new >> features request should go to the new list, Am I right? >> >> But looks there is little activity in coreutils@gnu.org, I have sent a= few patches related to cp(1) >> sparse file enhancement through fiemap ioctl(2), but almostly no respo= nse from the list members in >> about 2 weeks, except Joel I cc-ed. Maybe nobody is interesed. :( >> >> I know you guys are busy with work. Actually, I just want to know if = I was misunderstood the >> policy? If so, I will submit the patches here. >> >> Sorry for the inconvience! >=20 > Oops! > I was sure I had subscribed to that new list. > I've done so again in any case. >=20 > Patches should still go to bug-coreutils@gnu.org BTW. >=20 > I'm just catching up on work after holidays, > but a quick note Re: `cp --reflink` >=20 > We were trying to come up with a generic term for the CoW feature. > For BTRFS, `cp` currently needs to copy attributes explicitly, > but for OCFS2 we can just do the reflink and not bother with > all the attribute copying. The interface is fine as is I think. > If there is a generic interface for CoW in future, we can use that. >=20 Thanks for the response! one thing I need to point is, for OCFS2 reflink ioctl(2), it also has an attributes preserve option could be specified explictly. Joel has give me some feedback about this before, > +/* Perform the OCFS2 CoW reflink operation if possible. > > + We do not attempt to preserve security attributes for a reference > > + counted link. Instead, let 'x->preserve_xxxx' to process them if > > + they are the user expected. > > + Upon success, return 0, Otherwise, return -1 and set errno. */ > > +static inline int > > +reflink_file (char const *src_name, char const *dst_name, > > + int src_fd, bool *new_dst) > > +{ > > +#ifdef __linux__ > > +# ifndef REFLINK_ATTR_NONE > > +# define REFLINK_ATTR_NONE 0 > > +# endif If '-p' was specified, you should honor it with REFLINK_ATTR_PRESERVE. I can implement it only when cp(1) invoked with '-p' option without confl= ict to current `cp` preserve functions, then the default attributes will be reflink to the de= st file (i.e., mode,ownership,timestamps). currently, my idea is, when invoking cp with '--reflink=3D[WHEN]', it fir= st performing btrfs clone, if it failed, try to do ocfs2 reflink, fall back to normal copy if both o= f them failed. > cheers, > P=E1draig. >=20 Thanks, -Jeff From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 09 13:37:38 2010 Received: (at 5914) by debbugs.gnu.org; 9 Apr 2010 17:37:38 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0I9C-0000MK-4b for submit@debbugs.gnu.org; Fri, 09 Apr 2010 13:37:38 -0400 Received: from rcsinet12.oracle.com ([148.87.113.124]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0HpV-0000DI-N3 for 5914@debbugs.gnu.org; Fri, 09 Apr 2010 13:17:18 -0400 Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o39HH8FZ014828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Apr 2010 17:17:11 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o392neX9013118; Fri, 9 Apr 2010 17:17:08 GMT Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 162208741270833327; Fri, 09 Apr 2010 10:15:27 -0700 Received: from [130.35.68.118] (/130.35.68.118) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Apr 2010 10:15:26 -0700 Message-ID: <4BBF60AE.4050408@oracle.com> Date: Fri, 09 Apr 2010 10:15:26 -0700 From: Sunil Mushran User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "jeff.liu" Subject: Re: bug#5914: feature request and non-bug patches submit policy References: <4BBEF339.9060008@oracle.com> <87ochs4uxg.fsf@meyering.net> <4BBF43D1.3030403@oracle.com> In-Reply-To: <4BBF43D1.3030403@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4BBF6114.0118:SCFMA4539814,ss=1,fgs=0 X-Spam-Score: -6.6 (------) X-Debbugs-Envelope-To: 5914 X-Mailman-Approved-At: Fri, 09 Apr 2010 13:37:37 -0400 Cc: 5914@debbugs.gnu.org, Jim Meyering X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) jeff.liu wrote: >> Over the last few weeks I've been working on other projects >> (pretty must time dedicated to getting grep back into shape), >> so coreutils has languished. Sorry for not giving more feedback, >> but I have been watching. >> >> In fact, seeing the use of HAVE_FTRUNCATE that is moved by your patch >> is what prompted me to mark the ftruncate module as obsolete and remove >> that code from copy.c. >> >> While I'm writing, here's one high-level question for you. >> When would your new --fiemap-sync option be useful, and what change >> in semantics will I see between when I use it and when I don't? >> >> --fiemap-sync sync file data before fiemap\n\ >> > IMHO, there is no difference from the user's point of view with or without this option. > and on the kernel side, if FIEMAP_FLAG_SYNC was specified, it just do the dirty page process > regardless of the sync succeeds or failed due to ENOSPC or EIO or other errors. > > I need to do more investigation to answer this question. I would recommend using fiemap purely as a means to get the extent map to skip reading the holes when copying. That's it. And it should be used when available. No user options. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 09 15:21:58 2010 Received: (at 5914) by debbugs.gnu.org; 9 Apr 2010 19:21:58 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0JmA-0001as-Hn for submit@debbugs.gnu.org; Fri, 09 Apr 2010 15:21:58 -0400 Received: from acsinet11.oracle.com ([141.146.126.233]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0Jg3-0001YM-Jw for 5914@debbugs.gnu.org; Fri, 09 Apr 2010 15:15:40 -0400 Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by acsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o39JFXw9010978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Apr 2010 19:15:34 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o39JFU49010474; Fri, 9 Apr 2010 19:15:31 GMT Received: from ca-server1.us.oracle.com by acsmt354.oracle.com with ESMTP id 149834621270840529; Fri, 09 Apr 2010 12:15:29 -0700 Received: from jlbec by ca-server1.us.oracle.com with local (Exim 4.69) (envelope-from ) id 1O0Jft-0003p2-Aj; Fri, 09 Apr 2010 12:15:29 -0700 Date: Fri, 9 Apr 2010 12:15:29 -0700 From: Joel Becker To: "jeff.liu" Subject: Re: bug#5914: feature request and non-bug patches submit policy Message-ID: <20100409191529.GA9408@mail.oracle.com> References: <4BBEF339.9060008@oracle.com> <4BBF33E7.5020908@draigBrady.com> <4BBF4F0A.1090608@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BBF4F0A.1090608@oracle.com> X-Burt-Line: Trees are cool. X-Red-Smith: Ninety feet between bases is perhaps as close as man has ever come to perfection. User-Agent: Mutt/1.5.20 (2009-06-14) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BBF7CD5.0028:SCFMA4539814,ss=1,fgs=0 X-Spam-Score: -6.6 (------) X-Debbugs-Envelope-To: 5914 X-Mailman-Approved-At: Fri, 09 Apr 2010 15:21:57 -0400 Cc: Sunil Mushran , 5914@debbugs.gnu.org, =?iso-8859-1?Q?P=E1draig?= Brady , Tao Ma X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) On Sat, Apr 10, 2010 at 12:00:10AM +0800, jeff.liu wrote: > one thing I need to point is, for OCFS2 reflink ioctl(2), it also has an > attributes preserve option could be specified explictly. > > I can implement it only when cp(1) invoked with '-p' option without conflict to current `cp` > preserve functions, then the default attributes will be reflink to the dest file (i.e., > mode,ownership,timestamps). That's what I figured. > currently, my idea is, when invoking cp with '--reflink=[WHEN]', it first performing btrfs clone, > if it failed, try to do ocfs2 reflink, fall back to normal copy if both of them failed. A better approach would be to try the ocfs2 reflink ioctl(2), then the btrfs one. btrfs will support OCFS2_IOC_REFLINK eventually. Joel -- "What no boss of a programmer can ever understand is that a programmer is working when he's staring out of the window" - With apologies to Burton Rascoe Joel Becker Principal Software Developer Oracle E-mail: joel.becker@oracle.com Phone: (650) 506-8127 From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 10 04:42:32 2010 Received: (at 5914) by debbugs.gnu.org; 10 Apr 2010 08:42:32 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0WGt-0006c7-RU for submit@debbugs.gnu.org; Sat, 10 Apr 2010 04:42:32 -0400 Received: from smtp3-g21.free.fr ([212.27.42.3]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0WGq-0006c1-Mp for 5914@debbugs.gnu.org; Sat, 10 Apr 2010 04:42:30 -0400 Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 8C979818043; Sat, 10 Apr 2010 10:42:20 +0200 (CEST) Received: from mx.meyering.net (mx.meyering.net [82.230.74.64]) by smtp3-g21.free.fr (Postfix) with ESMTP id A8220818036; Sat, 10 Apr 2010 10:42:18 +0200 (CEST) Received: by rho.meyering.net (Acme Bit-Twister, from userid 1000) id 8BFACE5F; Sat, 10 Apr 2010 10:42:18 +0200 (CEST) From: Jim Meyering To: Sunil Mushran Subject: Re: bug#5914: feature request and non-bug patches submit policy In-Reply-To: <4BBF60AE.4050408@oracle.com> (Sunil Mushran's message of "Fri, 09 Apr 2010 10:15:26 -0700") References: <4BBEF339.9060008@oracle.com> <87ochs4uxg.fsf@meyering.net> <4BBF43D1.3030403@oracle.com> <4BBF60AE.4050408@oracle.com> Date: Sat, 10 Apr 2010 10:42:18 +0200 Message-ID: <87633zzok5.fsf@meyering.net> Lines: 27 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 5914 Cc: "jeff.liu" , 5914@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.9 (--) Sunil Mushran wrote: ... >>> While I'm writing, here's one high-level question for you. >>> When would your new --fiemap-sync option be useful, and what change >>> in semantics will I see between when I use it and when I don't? >>> >>> --fiemap-sync sync file data before fiemap\n\ >>> >> IMHO, there is no difference from the user's point of view with or without this option. >> and on the kernel side, if FIEMAP_FLAG_SYNC was specified, it just do the dirty page process >> regardless of the sync succeeds or failed due to ENOSPC or EIO or other errors. >> >> I need to do more investigation to answer this question. > > I would recommend using fiemap purely as a means to get the extent map to > skip reading the holes when copying. That's it. And it should be used when > available. No user options. I agree. Using fiemap is an optimization. Enable it if possible, otherwise, work as usual. No need for any change in the command-line interface. Jeff, please eliminate both --fiemap and --fiemap-sync in your next iteration. If someone makes a good case for exposing a fiemap-related option, we can always add it later. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 10 04:57:36 2010 Received: (at 5914) by debbugs.gnu.org; 10 Apr 2010 08:57:36 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0WVT-0006ha-Om for submit@debbugs.gnu.org; Sat, 10 Apr 2010 04:57:36 -0400 Received: from rcsinet12.oracle.com ([148.87.113.124]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0WVS-0006hV-8j for 5914@debbugs.gnu.org; Sat, 10 Apr 2010 04:57:34 -0400 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o3A8vT1L010028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 10 Apr 2010 08:57:30 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o39LiEUl015448; Sat, 10 Apr 2010 08:57:28 GMT Received: from abhmt009.oracle.com by acsmt355.oracle.com with ESMTP id 150721651270889841; Sat, 10 Apr 2010 01:57:21 -0700 Received: from [221.223.106.125] (/221.223.106.125) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 10 Apr 2010 01:57:21 -0700 Message-ID: <4BC03D8C.9020106@oracle.com> Date: Sat, 10 Apr 2010 16:57:48 +0800 From: "jeff.liu" User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Jim Meyering Subject: Re: bug#5914: feature request and non-bug patches submit policy References: <4BBEF339.9060008@oracle.com> <87ochs4uxg.fsf@meyering.net> <4BBF43D1.3030403@oracle.com> <4BBF60AE.4050408@oracle.com> <87633zzok5.fsf@meyering.net> In-Reply-To: <87633zzok5.fsf@meyering.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BC03D78.019C:SCFMA4539814,ss=1,fgs=0 X-Spam-Score: -6.6 (------) X-Debbugs-Envelope-To: 5914 Cc: Sunil Mushran , 5914@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) Jim Meyering wrote: > Sunil Mushran wrote: > ... >>>> While I'm writing, here's one high-level question for you. >>>> When would your new --fiemap-sync option be useful, and what change >>>> in semantics will I see between when I use it and when I don't? >>>> >>>> --fiemap-sync sync file data before fiemap\n\ >>>> >>> IMHO, there is no difference from the user's point of view with or without this option. >>> and on the kernel side, if FIEMAP_FLAG_SYNC was specified, it just do the dirty page process >>> regardless of the sync succeeds or failed due to ENOSPC or EIO or other errors. >>> >>> I need to do more investigation to answer this question. >> I would recommend using fiemap purely as a means to get the extent map to >> skip reading the holes when copying. That's it. And it should be used when >> available. No user options. > > I agree. Using fiemap is an optimization. > Enable it if possible, otherwise, work as usual. > No need for any change in the command-line interface. > > Jeff, please eliminate both --fiemap and --fiemap-sync > in your next iteration. > > If someone makes a good case for exposing a fiemap-related > option, we can always add it later. ok, the changes will be reflected in my next try. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 15 18:48:55 2010 Received: (at 5914-done) by debbugs.gnu.org; 15 Apr 2010 22:48:56 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O2Xrj-0000JN-Kg for submit@debbugs.gnu.org; Thu, 15 Apr 2010 18:48:55 -0400 Received: from joseki.proulx.com ([216.17.153.58]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O2Xri-0000JI-Gb for 5914-done@debbugs.gnu.org; Thu, 15 Apr 2010 18:48:55 -0400 Received: from dementia.proulx.com (dementia.proulx.com [192.168.230.115]) by joseki.proulx.com (Postfix) with ESMTP id C2355213A2; Thu, 15 Apr 2010 16:48:49 -0600 (MDT) Received: by dementia.proulx.com (Postfix, from userid 1000) id BA6983CC3A0; Thu, 15 Apr 2010 16:48:49 -0600 (MDT) Date: Thu, 15 Apr 2010 16:48:49 -0600 From: Bob Proulx To: "jeff.liu" Subject: Re: bug#5914: feature request and non-bug patches submit policy Message-ID: <20100415224849.GA27621@dementia.proulx.com> References: <4BBEF339.9060008@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BBEF339.9060008@oracle.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 5914-done Cc: 5914-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) jeff.liu wrote: > I'd like to know if I should still submit new feature patches to > here or coreutils@gnu.org. I think the original issue has been fully dealt with so I am going to close the issue in the bts. If you think otherwise please feel free to follow up with more information. This thread has gone through a little mutation during the discussion. I think the subsequent discussion around fiemap may still have some life in it but I think it has also mostly been resolved by discussion on the coreutils mailing list. In any case it probably shouldn't be here going forward. If that needs to continue then we should clone the issue and retitle it to track that development. When possible it is best to keep issues one per ticket. But since I think it has concluded here too I am just going to close it with the original. Bob From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 16 00:43:24 2010 Received: (at 5914) by debbugs.gnu.org; 16 Apr 2010 04:43:24 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O2dOl-0002Yw-QE for submit@debbugs.gnu.org; Fri, 16 Apr 2010 00:43:24 -0400 Received: from acsinet11.oracle.com ([141.146.126.233]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O2dOl-0002Yr-1K for 5914@debbugs.gnu.org; Fri, 16 Apr 2010 00:43:23 -0400 Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o3G4hHjt028906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Apr 2010 04:43:18 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3G4hFpD020202; Fri, 16 Apr 2010 04:43:16 GMT Received: from abhmt007.oracle.com by acsmt353.oracle.com with ESMTP id 180514871271392933; Thu, 15 Apr 2010 21:42:13 -0700 Received: from [10.182.120.235] (/10.182.120.235) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Apr 2010 21:42:13 -0700 Message-ID: <4BC7EAC5.9040603@oracle.com> Date: Fri, 16 Apr 2010 12:42:45 +0800 From: "jeff.liu" User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: 5914@debbugs.gnu.org, Bob Proulx Subject: Re: bug#5914: feature request and non-bug patches submit policy References: <4BBEF339.9060008@oracle.com> <20100415224849.GA27621@dementia.proulx.com> In-Reply-To: <20100415224849.GA27621@dementia.proulx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BC7EAE5.0072:SCFMA4539814,ss=1,fgs=0 X-Spam-Score: -6.6 (------) X-Debbugs-Envelope-To: 5914 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.6 (------) Bob Proulx wrote: > jeff.liu wrote: >> I'd like to know if I should still submit new feature patches to >> here or coreutils@gnu.org. > > I think the original issue has been fully dealt with so I am going to > close the issue in the bts. If you think otherwise please feel free > to follow up with more information. > > This thread has gone through a little mutation during the discussion. > I think the subsequent discussion around fiemap may still have some > life in it but I think it has also mostly been resolved by discussion > on the coreutils mailing list. In any case it probably shouldn't be > here going forward. If that needs to continue then we should clone > the issue and retitle it to track that development. When possible it > is best to keep issues one per ticket. But since I think it has > concluded here too I am just going to close it with the original. > Thanks for the heads up. -Jeff > Bob > > > > From unknown Wed Aug 20 04:11:25 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 14 May 2010 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator