Hi,
fyi
http://lwn.net/Articles/399148/
copyfile()
The reflink() http://lwn.net/Articles/333783/ system call was
originally proposed as a sort of fast copy operation; it would create a
new copy of a file which shared all of the data blocks. If one of the
files were subsequently written to, a copy-on-write operation would be
performed so that the other file would not change. LWN readers last
heard about this patch last September, when Linus refused to pull it
http://lwn.net/Articles/353048/ for 2.6.32. Among other things, he
didn't like the name.
So now reflink() is back as copyfile(), with some proposed additional
features. It would make the same copy-on-write copies on filesystems
that support it, but copyfile() would also be able to delegate the
actual copy work to the underlying storage device when it makes sense.
For example, if a file is being copied on a network-mounted filesystem,
it may well make sense to have the server do the actual copy work,
eliminating the need to move the data over the network twice. The system
call might also do ordinary copies within the kernel if nothing faster
is available.
The first question that was asked is: should copyfile() perhaps be an
asynchronous interface? It could return a file descriptor which could be
polled for the status of the operation. Then, graphical utilities could
start a copy, then present a progress bar showing how things were going.
Christoph Hellwig was adamant, though, that copyfile() should be a
synchronous operation like almost all other Linux system calls; there is
no need to create something weird and different here. Progress bars
neither justify nor require the creation of asynchronous interfaces.
There was also opposition to the mixing of the old reflink() idea with
that of copying a file. There is little perceived value in creating a
bad version of cp within the kernel. The two ideas were mixed because it
seems that Linus seems to want it that way, but, after this discussion,
they may yet be split apart again.
http://en.wikipedia.org/wiki/Btrfs
Btrfs provides a /clone/ operation which atomically creates a
copy-on-write snapshot of a file, support for
which was added to GNU coreutils
http://en.wikipedia.org/wiki/Coreutils 7.5.^[17]
http://en.wikipedia.org/wiki/Btrfs#cite_note-16 ^[18]
http://en.wikipedia.org/wiki/Btrfs#cite_note-17 Cloning from byte
ranges in one file to another is also
supported, allowing large files to be more efficiently manipulated
like standard rope
http://en.wikipedia.org/wiki/Rope_%28computer_science%29 data structures.
Also see http://www.symantec.com/connect/virtualstoreserver
--
Robert Milkowski
http://milek.blogspot.com
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
