Jim Meyering wrote: ... > I chose /proc/kallsyms: > > $ cp /proc/kallsyms /dev/shm/k > $ wc -c /proc/kallsyms /dev/shm/k > 1492084 /proc/kallsyms > 4090 /dev/shm/k > > I was surprised to see different results when copying to /tmp: > > $ cp /proc/kallsyms /tmp/k > $ wc -c /proc/kallsyms /tmp/k > 1492084 /proc/kallsyms > 1492084 /tmp/k > > That's because the two devices have different fundamental block sizes: > > $ stat -f --format '%S %n' /dev/shm/k /tmp/k > 4096 /dev/shm/k > 1024 /tmp/k > > and cp chooses its input buffer size based on that. > With the smaller block size, cp happens to avoid the short read problem.
Another interesting tidbit: cp copies that 1.5MB file using a measly 1024-byte buffer because the kernel (via stat) reports the size as "0" bytes. But this is /proc after all, and there are few large files there, and even if there were many, how often do people copy them? I don't plan to try to optimize for such a rare case. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
