On 12/19/2012 10:00 PM, Dave Chinner wrote:
[...]
I git cloned the coreutils to look at current state of the code, and
saw exactly what is represented on slide 14.
"Brute force – read each sector in full, before
skipping while writing the copy"
http://code.metager.de/source/xref/coreutils/src/extent-scan.c
It uses FIEMAP.
Indeed, take a 1TB sparse file (empty) and copy it:
$ cp --version
cp (GNU coreutils) 8.13
$ ls -lh blah
-rw-r--r-- 1 root root 1.0T Nov 30 06:42 blah
$ xfs_bmap -v blah
blah: no extents
$ strace cp --sparse=always blah fred
.....
stat("fred", 0x7fff98d7ded0) = -1 ENOENT (No such file or directory)
stat("blah", {st_mode=S_IFREG|0600, st_size=1099511627776, ...}) = 0
stat("fred", 0x7fff98d7dc50) = -1 ENOENT (No such file or directory)
open("blah", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0600, st_size=1099511627776, ...}) = 0
open("fred", O_WRONLY|O_CREAT|O_EXCL, 0600) = 4
fstat(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
ioctl(3, FS_IOC_FIEMAP, 0x7fff98d7c9d0) = 0
ftruncate(4, 1099511627776) = 0
close(4) = 0
close(3) = 0
...
$ xfs_bmap -v fred
fred: no extents
$
Looks like cp already does what you want - it didn't copy a TB Of
zeros..... ;)
I have much older coreutils by default on CentOS 6.x. Will recheck this
with newer version, and pull down the extent-scan. My strace had lots
of zeros ...
And what you really want is a version of cp that supports these:
[...]
Was thinking of hacking something up at a much higher level
(cheating by parsing bmap data and stuff like that).
Don't. You'll only get it wrong, just like the initial attempts to
use FIEMAP in cp did. There's a reason coreutils is moving to
SEEK_HOLE/SEEK_DATA instead of FIEMAP for efficient sparse file
handling....
Thanks. This isn't what I wanted to do if I could avoid it.
Cheers,
Dave.
--
Joe
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
