[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#5914: feature request and non-bug patches submit policy

From: jeff.liu
Subject: bug#5914: feature request and non-bug patches submit policy
Date: Sat, 10 Apr 2010 00:00:10 +0800
User-agent: Thunderbird (X11/20080505)

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

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.,

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 

> cheers,
> Pádraig.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]