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
>> [email protected].
>>
>> A few months ago, I found the heads up for the new [email protected] 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 [email protected], 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 [email protected] 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
