On Mon, Sep 30, 2013 at 4:17 PM, Dan Shelton <[email protected]> wrote: > I'm just forwarding the old conversation as a reminder - AST pax still > does not support SEEK_HOLE or SEEK_DATA (nor does it SUN.holesdata pax > header), nor do AST cp and mv support files with holes. > > As consequence neither AST pax, cp or mv are competitive to any of > such implementations which support SEEK_HOLE and SEEK_DATA. > > For example moving a 200GB file with 99% holes with GNU mv (GNU > supports SEEK_HOLE/SEEK_DATA since 2010) across filesystem takes less > than a 4 seconds with GNU mv but takes a WHOPPING 18 minutes with AST > mv. [snip]
Erm... ... AFAIK a copy-file-data algorithm would be just this: 1. Test whether $ getconf MIN_HOLE_SIZE <srcpath> # returns a value > 0 2. If [1] is true then check whether the file has at least one hole (via |SEEK_HOLE|) 3. If [2] is true switch to a special version of the data copying code which "simply" copies data via |write()| until it hits a hole and then uses |lseek()| to seek forward to the next position and then uses |write()| again. Glenn: Does that sound correct ? ---- Bye, Roland P.S.: Testing: Files with holes at the start, at the end, in the middle, files which are a giant, single hole... -- __ . . __ (o.\ \/ /.o) [email protected] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ ast-users mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-users
