[LSF/Filesystems][ATTEND]

* [LSF/Filesystems][ATTEND]
       [not found] <alpine.LFD.2.00.1005171556240.16844@jlentini-linux.nane.netapp.com>
@ 2010-05-17 21:23 ` Madan, Anshul
  2010-05-17 22:24   ` [LSF/Filesystems][ATTEND] Joel Becker
  0 siblings, 1 reply; 3+ messages in thread
From: Madan, Anshul @ 2010-05-17 21:23 UTC (permalink / raw)
  To: lsf10-pc; +Cc: linux-fsdevel, Lentini, James, Myklebust, Trond, Joel.Becker

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

^ permalink raw reply	[flat|nested] 3+ messages in thread