RE: copy offload support in Linux - new system call needed?

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

 



> > virtualization vendors who support this offload do it at a layer
> above the guest-OS(Intra-LUN(tm) locking or whatever fancy locking). So
> I think 'copyfile' is going to be appealing to application-developers
> more than the hypervisor-vendors.
> 
> The application is thin provisioning, not the 'cp' command. When


thin-provisioning is one use-case. There are quite a few use-cases of 'copyfile' depending on your business-logic and the type of appliance you sell.


> virtualisation vendors do support this, it will mainly be as part of
> their image management toolkits, not the hypervisor.
> 

Toolkits? May not be true. The toolkit might need to talk to some hypervisor-component to ensure LUN-locking etc on the target. So this is not entirely isolated as you might think. There is some integration. As an example(just to prove the point) - Have you ever seen anyone not use vsphere-client on VMware for copying VM templates?


> > So let's think about it from end-users perspective:
> > Won't everyone replicate code to check - 'Am I done'? It will just
> make application folks write more (ugly)code. Because you would then
> have to maintain another queue/etc to check for this operation.
> 
> 'Am I done' is easy: copyfile() returns with the number of bytes that
> have been copied.
> 
> 'Is my copyfile() syscall making progress' is the question that needs
> answering.
> 

Understood. But as a user, we don't know what 'am I done' is going to report.

'am I done' can return:
1)ACK[copy done] - simplistic case.
2)IN-progress.
3)NACK[copy failed(with status values) or copy partially completed]

And if you are using the copy-VM use-case then very few VMs are under 4GBs. So we will hit 2) above more frequently than 1) and 3).


> > We can just support full-copy. Partial copies can be returned as
> failure.
> 
> Then you have to check the entire range on error instead of just
> resuming the copy from where it stopped.
> 

Why not restart? What if the LUN was implementing thin-provisioning and now it ran out-of-space after partially copying your data.
So why not restart the copy? If the target doesn't support auto-extend, someone(storage-admin etc) would have to step-in and manage that LUN.
You might as-well restart the copy in this case.



Chetan Loke


��.n��������+%������w��{.n�����{������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux