[LSF/Filesystems][ATTEND]

[LSF/Filesystems][ATTEND]

[Madan, Anshul]

Requesting Attendance:

Trond Myklebust, James Lentini and Anshul Madan


Proposal:

We propose to discuss the design and implementation issues involved in 
introducing a new copy() system call into the Linux kernel. The goal 
of this session would be to determine the required functionality and 
obtain a general consensus on the necessary VFS interface changes. We 
believe that the LSF Summit offers a unique opportunity to discuss 
this topic and gain consensus with developers from several different 
file system communities.

We are implementing the NFS copy offload operations and associated 
system call(s). We would contribute to the discussions on API 
capabilities, design issues, and other VFS issues. We would provide 
insights into different design trade-offs in the VFS layer, and also 
report on the progress of our implementation.  


Keywords: File systems


Background:

There is an emerging trend for file systems to support intelligent 
copies. OCFS2 supports intelligent copies via a reflink ioctl(2). At 
the same time, a proposal has been made for the NFS protocol to 
support intelligent copy operations, see IETF draft 
draft-lentini-nfsv4-server-side-copy. We expect other file systems to 
add support for intelligent copy capabilities in the future. To take 
full advantage of these capabilities, the Linux kernel's system call 
interface must be expanded to allow userspace applications to use this 
feature in a uniform way.

This topic has been discussed both on Linux development mailing lists 
[1] and at previous LSF summits. Joel Becker originally proposed a 
syscall called reflink() that was specific to copying an inode to a 
copy-on-write snapshot. Since then, the need for a generic copy 
interface  that encompassed the reflink semantics as well as less 
restrictive ones has been recognized based on discussion between Linus 
Torvalds and Joel.


Motivation:

Intelligent copies have performance advantages over a traditional 
read/write copy. 

With data deduplication, fragments of data can be shared between 
files. Thus using conventional syscalls like read() and write() for 
doing a copy may lead to the unnecessary data transfers to and from 
the file system. Using a copy() syscall, the file system can make use 
of it's intelligence and thus avoid unnecessary data transfers.

The IT trend toward virtualization via hypervisors has created an 
emerging use case to copy a virtual disk over NFS. The use of a copy 
operation will save network bandwidth on the client and server, and 
intra-server file copy has the potential to avoid all physical data 
copies, if the file system is deduplicated as described above. 
Implementing a VFS inode operation which has a generic interface 
applicable to all types of file systems would allow applications to 
access this functionality in a uniform way. The VFS copy() inode 
operation and corresponding interface should encompass the semantics 
of various file system copy() implementations, such as support for 
asynchronous copies, copy status, and copy abort calls.

---

[1] Relevant posts:

http://www.mail-archive.com/ocfs2-devel@oss.oracle.com/msg04347.html
http://www.mail-archive.com/ocfs2-devel@oss.oracle.com/msg04395.html
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [LSF/Filesystems][ATTEND]

[Joel Becker]

On Mon, May 17, 2010 at 05:23:22PM -0400, Madan, Anshul wrote:
> Requesting Attendance:
> 
> Trond Myklebust, James Lentini and Anshul Madan

	I (Joel Becker ) would like to request attendance to join in
this conversation.  I'm the original proposer of reflink(2).

> This topic has been discussed both on Linux development mailing lists 
> [1] and at previous LSF summits. Joel Becker originally proposed a 
> syscall called reflink() that was specific to copying an inode to a 
> copy-on-write snapshot. Since then, the need for a generic copy 
> interface  that encompassed the reflink semantics as well as less 
> restrictive ones has been recognized based on discussion between Linus 
> Torvalds and Joel.

	My last proposal for the copyfile(2) interface is reference [2].
I think it is a good starting point, but I'm very interested in what the
network filesystem community has to say.  NFS's server copy capability
is something I definitely had in mind.

> [1] Relevant posts:
> 
> http://www.mail-archive.com/ocfs2-devel@oss.oracle.com/msg04347.html
> http://www.mail-archive.com/ocfs2-devel@oss.oracle.com/msg04395.html

Joel

-- 

"Reader, suppose you were and idiot.  And suppose you were a member of
 Congress.  But I repeat myself."
	- Mark Twain

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Lsf10-pc] [LSF/Filesystems][ATTEND]

[Ric Wheeler]

On 05/17/2010 06:24 PM, Joel Becker wrote:
> On Mon, May 17, 2010 at 05:23:22PM -0400, Madan, Anshul wrote:
>    
>> Requesting Attendance:
>>
>> Trond Myklebust, James Lentini and Anshul Madan
>>      
> 	I (Joel Becker ) would like to request attendance to join in
> this conversation.  I'm the original proposer of reflink(2).
>
>    
>> This topic has been discussed both on Linux development mailing lists
>> [1] and at previous LSF summits. Joel Becker originally proposed a
>> syscall called reflink() that was specific to copying an inode to a
>> copy-on-write snapshot. Since then, the need for a generic copy
>> interface  that encompassed the reflink semantics as well as less
>> restrictive ones has been recognized based on discussion between Linus
>> Torvalds and Joel.
>>      
> 	My last proposal for the copyfile(2) interface is reference [2].
> I think it is a good starting point, but I'm very interested in what the
> network filesystem community has to say.  NFS's server copy capability
> is something I definitely had in mind.
>
>    
>> [1] Relevant posts:
>>
>> http://www.mail-archive.com/ocfs2-devel@oss.oracle.com/msg04347.html
>> http://www.mail-archive.com/ocfs2-devel@oss.oracle.com/msg04395.html
>>      
> Joel
>    

I think that this would be an interesting subject as well, especially 
given the mix of storage & FS people at the event.

Ric