[coreutils] Re: Feature: add ocfs2 reflink to cp(1)

[jeff.liu]

Joel Becker wrote:
> On Sun, Apr 04, 2010 at 11:44:48PM +0800, jeff.liu wrote:
>> +/* This function detects whether the source and destination files
>> +   are all resides on OCFS2.  If true, then perform the OCFS2 reflink
>> +   operation.  Otherwise, performing btrfs clone operation.  */
>> +static inline bool
>> +is_ocfs2_file (int dst_fd, int src_fd)
>> +{
>> +#if HAVE_FSTATFS && HAVE_STRUCT_STATFS_F_TYPE && defined __linux__
>> +  struct statfs statfsbuf1;
>> +  struct statfs statfsbuf2;
>> +
>> +  return (fstatfs (src_fd, &statfsbuf1) == 0
>> +          && statfsbuf1.f_type == S_MAGIC_OCFS2
>> +          && fstatfs (dst_fd, &statfsbuf2) == 0
>> +          && statfsbuf2.f_type == S_MAGIC_OCFS2);
>> +#else
>> +  (void) dst_fd;
>> +  (void) src_fd;
>> +  return false;
>> +#endif
>> +}
> 
>       I don't know that the correct behavior is btrfs' when ocfs2 is
> not detected.
Looks I should not implement 'is_ocfs2_file()' here, it add a bit extra 
indistinct noise.
Now my idea is just performing either btrfs clone or ocfs2 reflink operation if 
cp(1) invoked with
'--reflink=[WHEN]'.
If both of them failed no matter what the reason is, fall back to normal copy 
process when the
reflink mode is 'REFLINK_AUTO', or abort.

> 
>> +/* 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.
Thanks for pointing this out.  At first, I think the file attributes preserve 
should managed through
normal copy,  its wrong, I will fix it in the next patch submit.

> Joel
> 

Thanks,
-Jeff