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

Previous Next

Full log

View this message in rfc822 format

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: 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

Previous Next

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