[Bug 223955] cpio needs a --block-size= option

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223955

            Bug ID: 223955
           Summary: cpio needs a --block-size= option
           Product: Base System
           Version: 9.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: bin
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: rfg at tristatelogic.com

I didn't get the memo, so I'm only just now finding out that "cpio -p"
        can be WAAAAAY slower than "cp" for the same file, at least on my
        Ubuntu/Linux system.  I have some reason to believe that this will be
        true if I test it also on FreeBSD.  (The issue seems like it will
        be the same on both systems.)

        The problem seems to be that the default I/O block size used by cpio...
        left over from ancient times (e.g. 1970's) is 512 bytes.  This can
        be increased somewhat (to 5120 bytes) using the -B option, however
        in the current era of large media files and multi-terabyte disk
        drives... many of which themselves have a native hardware block size
        of 4 KiB... even a block size of 5120 bytes is ludicrously small,
        and causes a massive performance hit.

        The Linux people, at least, seems to have recognzied the issue, and
        have added a --block-size= option to their version of cpio.  I think
        it's well past time that FreeBSD followed suit and did likewise.

Environment:
System: FreeBSD segfault.tristatelogic.com 9.1-RELEASE FreeBSD 9.1-RELEASE #0
r243825: Tue Dec 4 09:23:10 UTC 2012
root at farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64

How-To-Repeat:
Just try copying a large file multi-gigabyte file using "cpio -p"
        and time the command.  Then, using a different file of about the
        same size, just do the same thing using "cp" and time that also.
        On Ubuntu, at least, there is a stunning 6.92x speed difference.
        I know.  I measured it.

Fix:
Sorry.  No.  I don't have the code patches to implement this suggestion.
        but I felt that it was worth making the suggestion anyway.

-- 
You are receiving this mail because:
You are the assignee for the bug.