Re: BTRFS file clone support for cp

[Giuseppe Scrivano]

Jim Meyering <address@hidden> writes:

> Doesn't that constant, 1074041865, have a symbolic name?
> Maybe BTRFS_IOC_CLONE?

Yes, it is exactly BTRFS_IOC_CLONE and it is defined in the
fs/btrfs/ioctl.h file.


>> Is there an easy and quick way to determine which file system is used by
>> a file?  Probably it would be safer to add a guard around the ioctl
>> call.
>
> Before thinking about that, I'd like to know the approximate cost
> of the failing ioctl, e.g., on a kernel with btrfs support and
> on one without, in case that makes a difference.  I.e., what impact
> would it have if left unprotected?  Does it make a measurable difference
> when copying 20K empty files on a tmpfs file system?
>
> If necessary, we can avoid almost all of the per-file ioctl calls
> via a map that associates each distinct device number encountered
> with a boolean "is btrfs file system".  gnulib's fts does something
> similar, but its goal is to determine whether a different FS-specific
> performance optimization is likely to help.

I didn't notice any difference using a patched and an un-patched cp on
tmpfs.

To go more in detail I used this simple test:

  int src = open ("foo", O_RDONLY);
  int dest = open ("bar", O_WRONLY | O_CREAT, 0777);

  assert (src);
  assert (dest);

  for (i = 0; i < ITERATIONS; i++)
    if (!ioctl (dest, 1074041865, src))
      error (1, 0, "cannot be successful!");

  close (src);
  close (dest);


On BTRFS, it raises correctly the "cannot be successful!" message.


Either on EXT3 and TMPFS the result is similar.


With 100000 iterations:

0.01user 0.00system 0:00.01elapsed 118%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+120minor)pagefaults 0swaps


With 10000000 iterations:

0.68user 0.82system 0:01.50elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+119minor)pagefaults 0swaps


Regards,
Giuseppe