<div dir="ltr"><div style>In BD xlator cloning refers to full copy of the file (after the copy there is no relationship between these 2 files). Snapshot refers to COW of the file. I guess these terminologies need to be generalized. I can choose "copy" for full copy functionality and either "clone" or "snapshot" for COW functionality.</div>
<div><br></div><div>Sorry, I could not go through complete qemu-block xlator code. If I understand correctly your patch (<a href="http://review.gluster.com/#/c/5967/">http://review.gluster.com/#/c/5967/</a>) also expects destination file to exist before cloning? ie in '<span style="color:rgb(53,53,53);font-size:9pt">setxattr -n trusted.glusterfs.block-format -v "qcow2:10GB:<bimg>" ./newimage', </span>the file newimage exists before calling this operation, isn't it?</div>
<div style><br></div><div>BD patches allow users to specify full path of the destination file as part of xattr value because thats how management tools pass the path for creating snapshot or complete copy of a KVM image. Current interface for offloaded functionality for BD: # setfattr -n [clone|snapshot] -v "/path/to/destination-file" path-to-source-file. So IIUC in both the approaches we need to validate both source and destination files or am I missing something here?</div>
<div style><br></div><div style>Also how about listing snapshots/origin for a given file and ability to merge the external snapshot file to the origin? BD xlator has the capability to list origin (ie gfid) for a given snapshot, but listing snapshots for a given file is not implemented.</div>
<div style><br></div><div style>Anand, shall I post the patches to gerrit, may be next round we can decide about the interfaces for offload operations?</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Sep 25, 2013 at 6:20 PM, Brian Foster <span dir="ltr"><<a href="mailto:bfoster@redhat.com" target="_blank">bfoster@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 09/25/2013 12:27 AM, M. Mohan Kumar wrote:<br>
> Here is the right link: <a href="http://review.gluster.org/#/c/5626/" target="_blank">http://review.gluster.org/#/c/5626/</a><br>
><br>
<br>
</div>Thanks guys. I haven't taken a deep look at the code, but some initial<br>
high-level comments...<br>
<br>
The first thing I notice is that we take the opposite approach in the<br>
associated qemu-block command. The target of the clone command is the<br>
new file (referencing the source) rather than the original file passing<br>
in a name of the target. Personally, I find the former more natural as a<br>
core interface. The error handling is more straightforward (i.e.,<br>
ENOENT) and it matches more closely with native primitives that provide<br>
this kind of functionality (i.e., correct me if wrong, but I think we<br>
observed that btrfs clone works via ioctl on the target fd, providing<br>
the source fd as a parameter).<br>
<br>
That said, I'm not sure if that is considered more user-friendly or not.<br>
If that's a concern, could we change the low level interface to work as<br>
described (i.e., user issues command on source file, high level code<br>
converts into command on target file)? IOW, I think a nice goal going<br>
forward would be to have the low level mechanisms standardize on some<br>
kind of ioctl, and the higher level code become convenience commands<br>
that simply exercise the ioctl (and what actually happens after that<br>
depends on the type of file, what translators are loaded, etc.). I guess<br>
that's hand wavy at the moment, but the idea is that all of this path<br>
resolving and whatnot becomes generic and independent rather than<br>
specific to and duplicated across each snapshot/clone mechanism we provide.<br>
<br>
Secondarily, but somewhat related... does the path resolving code that<br>
is there now have to be buried in fuse-bridge? Avati and I have briefly<br>
discussed this idea of separating the management here into an<br>
independent translator, and I think this falls in as a perfect candidate<br>
for something like that. The resolving code is non-trivial, however, so<br>
I'm not sure if there are serious technical hurdles for that kind of<br>
approach. For example, is it possible/reasonable to push this into a new<br>
translator beneath fuse (or perhaps library code?) and just skip linking<br>
the inode into the parent table until/unless that happens naturally?<br>
Thoughts?<br>
<span class="HOEnZb"><font color="#888888"><br>
Brian<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> On Wed, Sep 25, 2013 at 6:53 AM, M. Mohan Kumar <<a href="mailto:mohankumar.m@gmail.com">mohankumar.m@gmail.com</a>>wrote:<br>
><br>
>><br>
>><br>
>> <a href="http://review.gluster.org/#/q/owner:%22M.+Mohan+Kumar+%253Cmohan%2540in.ibm.com%253E%22,n,z" target="_blank">http://review.gluster.org/#/q/owner:%22M.+Mohan+Kumar+%253Cmohan%2540in.ibm.com%253E%22,n,z</a><br>
>><br>
>> I also replied to your other comments.<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On Wednesday, September 25, 2013, Anand Avati <<a href="mailto:avati@gluster.org">avati@gluster.org</a>> wrote:<br>
>>> Adding Brian Foster (and gluster-devel) for the discussion of unified UI<br>
>> for snapshotting.<br>
>>> Mohan, I must have missed your comment. Can you please point to the<br>
>> specific patch where you posted your comment?<br>
>>> Avati<br>
>>><br>
>>> On Tue, Sep 24, 2013 at 9:29 AM, M. Mohan Kumar <<a href="mailto:mohankumar.m@gmail.com">mohankumar.m@gmail.com</a>><br>
>> wrote:<br>
>>>><br>
>>>> Hi Avati,<br>
>>>> I am ready with V5 of BD xlator patches (I consolidated the patches to<br>
>> 5). Before posting them I wanted your opinion about the interfaces I use<br>
>> for creating clone and snapshot. I posted them on Gerrit few days back.<br>
>> Could you please respond to that?<br>
>>>><br>
>>>> --<br>
>>>> Regards,<br>
>>>> Mohan.<br>
>>><br>
>><br>
>> --<br>
>> Regards,<br>
>> Mohan.<br>
>><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Regards,<br>Mohan.
</div>