Jim Meyering <[email protected]> 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
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
