diff options
| author | Jim Meyering <meyering@redhat.com> | 2011-04-20 11:21:09 +0200 |
|---|---|---|
| committer | Jim Meyering <meyering@redhat.com> | 2011-04-20 18:48:48 +0200 |
| commit | 18a474d755aa10d881243d9457d2c420c5e4ea77 (patch) | |
| tree | 4df68a02135e49569c3287ca0e25b886d9ba9732 /NEWS | |
| parent | 846d826096fc8fb621d751f8b3db1da68a8bbd06 (diff) | |
| download | coreutils-18a474d755aa10d881243d9457d2c420c5e4ea77.tar.xz | |
copy: use FIEMAP (extent_copy) only for apparently-sparse files,
to avoid the expense of extent_copy's unconditional use of
FIEMAP_FLAG_SYNC.
* src/copy.c (copy_reg): Do not attempt extent_copy on a file
that appears to have no holes.
* NEWS (Changes in behavior): Document this. At first I labeled this
as a bug fix, but that would be inaccurate, considering there is no
documentation of FIEMAP semantics, nor even consensus among kernel
FS developers. Here's hoping SEEK_HOLE/SEEK_DATA support will soon
make it into the linux kernel.
Diffstat (limited to 'NEWS')
| -rw-r--r-- | NEWS | 13 |
1 files changed, 13 insertions, 0 deletions
@@ -2,6 +2,19 @@ GNU coreutils NEWS -*- outline -*- * Noteworthy changes in release ?.? (????-??-??) [?] +** Changes in behavior + + cp's extent-based (FIEMAP) copying code is more reliable in the face + of varying and undocumented file system semantics: + - it no longer treats unwritten extents specially + - a FIEMAP-based extent copy always uses the FIEMAP_FLAG_SYNC flag. + Before, it would incur the performance penalty of that sync only + for 2.6.38 and older kernels. We thought all problems would be + resolved for 2.6.39. + - it now attempts a FIEMAP copy only on a file that appears sparse. + Sparse files are relatively unusual, and the copying code incurs + the performance penalty of the now-mandatory sync only for them. + * Noteworthy changes in release 8.11 (2011-04-13) [stable] |