GNU bug report logs - #5914
feature request and non-bug patches submit policy

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 5914 in the body.
You can then email your comments to 5914 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "jeff.liu" <jeff.liu <at> oracle.com>
To: bug-coreutils <at> gnu.org
Subject: feature request and non-bug patches submit policy
Date: Fri, 09 Apr 2010 17:28:25 +0800

Hi Jim,

I'd like to know if I should still submit new feature patches to here or coreutils <at> gnu.org.

A few months ago, I found the heads up for the new coreutils <at> 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 <at> 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

Message #8 received at 5914 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: "jeff.liu" <jeff.liu <at> oracle.com>
Cc: 5914 <at> debbugs.gnu.org
Subject: Re: bug#5914: feature request and non-bug patches submit policy
Date: Fri, 09 Apr 2010 15:28:11 +0200

jeff.liu wrote:
> Hi Jim,
>
> I'd like to know if I should still submit new feature patches to here or coreutils <at> gnu.org.
>
> A few months ago, I found the heads up for the new coreutils <at> 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 <at> 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.

Message #11 received at 5914 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: "jeff.liu" <jeff.liu <at> oracle.com>
Cc: 5914 <at> debbugs.gnu.org
Subject: Re: bug#5914: feature request and non-bug patches submit policy
Date: Fri, 09 Apr 2010 15:04:23 +0100

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 <at> gnu.org.
> 
> A few months ago, I found the heads up for the new coreutils <at> 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 <at> 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 <at> 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.

Message #14 received at 5914 <at> debbugs.gnu.org (full text, mbox):

From: "jeff.liu" <jeff.liu <at> oracle.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: Sunil Mushran <sunil.mushran <at> oracle.com>, 5914 <at> debbugs.gnu.org
Subject: Re: bug#5914: feature request and non-bug patches submit policy
Date: Fri, 09 Apr 2010 23:12:17 +0800

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 <at> gnu.org.
>>
>> A few months ago, I found the heads up for the new coreutils <at> 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 <at> 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

Message #17 received at 5914 <at> debbugs.gnu.org (full text, mbox):

From: "jeff.liu" <jeff.liu <at> oracle.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: Sunil Mushran <sunil.mushran <at> oracle.com>, 5914 <at> debbugs.gnu.org,
	Joel Becker <Joel.Becker <at> oracle.com>, Tao Ma <tao.ma <at> oracle.com>
Subject: Re: bug#5914: feature request and non-bug patches submit policy
Date: Sat, 10 Apr 2010 00:00:10 +0800

Pádraig 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 <at> gnu.org.
>>
>> A few months ago, I found the heads up for the new coreutils <at> 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 <at> 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 <at> 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.
> 
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 conflict to current `cp`
preserve functions, then the default attributes will be reflink to the dest file (i.e.,
mode,ownership,timestamps).

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.

> cheers,
> Pádraig.
> 

Thanks,
-Jeff

Message #20 received at 5914 <at> debbugs.gnu.org (full text, mbox):

From: Sunil Mushran <sunil.mushran <at> oracle.com>
To: "jeff.liu" <jeff.liu <at> oracle.com>
Cc: 5914 <at> debbugs.gnu.org, Jim Meyering <jim <at> meyering.net>
Subject: Re: bug#5914: feature request and non-bug patches submit policy
Date: Fri, 09 Apr 2010 10:15:26 -0700

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.

Message #23 received at 5914 <at> debbugs.gnu.org (full text, mbox):

From: Joel Becker <Joel.Becker <at> oracle.com>
To: "jeff.liu" <jeff.liu <at> oracle.com>
Cc: Sunil Mushran <sunil.mushran <at> oracle.com>, 5914 <at> debbugs.gnu.org,
	Pádraig Brady <P <at> draigBrady.com>,
	Tao Ma <tao.ma <at> oracle.com>
Subject: Re: bug#5914: feature request and non-bug patches submit policy
Date: Fri, 9 Apr 2010 12:15:29 -0700

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 <at> oracle.com
Phone: (650) 506-8127

Message #26 received at 5914 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Sunil Mushran <sunil.mushran <at> oracle.com>
Cc: "jeff.liu" <jeff.liu <at> oracle.com>, 5914 <at> debbugs.gnu.org
Subject: Re: bug#5914: feature request and non-bug patches submit policy
Date: Sat, 10 Apr 2010 10:42:18 +0200

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.

Message #29 received at 5914 <at> debbugs.gnu.org (full text, mbox):

From: "jeff.liu" <jeff.liu <at> oracle.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: Sunil Mushran <sunil.mushran <at> oracle.com>, 5914 <at> debbugs.gnu.org
Subject: Re: bug#5914: feature request and non-bug patches submit policy
Date: Sat, 10 Apr 2010 16:57:48 +0800

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.

Message #34 received at 5914-done <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: "jeff.liu" <jeff.liu <at> oracle.com>
Cc: 5914-done <at> debbugs.gnu.org
Subject: Re: bug#5914: feature request and non-bug patches submit policy
Date: Thu, 15 Apr 2010 16:48:49 -0600

jeff.liu wrote:
> I'd like to know if I should still submit new feature patches to
> here or coreutils <at> 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

Message #37 received at 5914 <at> debbugs.gnu.org (full text, mbox):

From: "jeff.liu" <jeff.liu <at> oracle.com>
To: 5914 <at> debbugs.gnu.org, Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#5914: feature request and non-bug patches submit policy
Date: Fri, 16 Apr 2010 12:42:45 +0800

Bob Proulx wrote:
> jeff.liu wrote:
>> I'd like to know if I should still submit new feature patches to
>> here or coreutils <at> 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
> 
> 
> 
> 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.