[PATCH 1/2] zhashfs, detect fill pattern and suppress blocks in output

Tue Apr 26 18:13:34 EDT 2011

> I think all of those are safe assumptions to make, and that FIEMAP is
> the more correct and efficient way of doing this.

Here's a reason not to: FIEMAP doesn't actually work yet (or, alternatively,
since its behavior is undocumented, you can't depend on its behavior):

From: Jim Meyering <jim at meyering.net>
To: info-gnu at gnu.org
Subject: coreutils-8.12 released [stable]
Mail-Followup-To: coreutils at gnu.org
Date: Tue, 26 Apr 2011 20:41:48 +0200
Message-ID: <87y62w97o3.fsf at rho.meyering.net>
Cc: coordinator at translationproject.org, coreutils at gnu.org,
   coreutils-announce at gnu.org
List-Id: Announcements and Requests for Help from the GNU project and the Free
	Software Foundation <info-gnu.gnu.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

This is to announce coreutils-8.12, a stable release.

We released coreutils-8.11 less than two weeks ago.
Why a new release so soon?  Because under unusual conditions,
coreutils-8.11's copying code could cause trouble.  Data loss trouble.
The trouble could arise only when these conditions are all met:
  - when using linux-2.6.39-related kernels (including at least -rc3) and
  - using an xfs file system and
  - copying (via cp, install, mv) a file with a so-called "unwritten
      extent" shortly after it has been created, yet before some
      data in that unwritten extent has made it to disk.
      This would happen if you're using the "gold" linker, which
      preallocates using fallocate and then writes its output
      (the binaries) into those unwritten extents, and you then
      immediately copy those binaries into place via "make install".
Under those conditions, just building coreutils and running "make
install" quickly enough after compile and link would result in
installing files containing all 0 bytes.

See the commit logs for links to plenty of discussion.
See the NEWS below for a brief summary.

Jim [on behalf of the coreutils maintainers]

- - -------------------------------------------
P.S. here's the GNU Coreutils home page:
    http://www.gnu.org/software/coreutils/

For a summary of changes and contributors, see:
  http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=shortlog;h=v8.12
or run this command from a git-cloned coreutils directory:
  git shortlog v8.11..v8.12

To summarize the many gnulib-related changes, run these commands from
a git-cloned coreutils directory:
  git checkout v8.12
  git submodule summary v8.11

Here are the compressed sources:
  http://ftp.gnu.org/gnu/coreutils/coreutils-8.12.tar.gz   (11MB)
  http://ftp.gnu.org/gnu/coreutils/coreutils-8.12.tar.xz   (4.7MB)

Here are the GPG detached signatures[*]:
  http://ftp.gnu.org/gnu/coreutils/coreutils-8.12.tar.gz.sig
  http://ftp.gnu.org/gnu/coreutils/coreutils-8.12.tar.xz.sig

To reduce load on the main server, use a mirror listed at:
  http://www.gnu.org/order/ftp.html

[*] You can use either of the above signature files to verify that
the corresponding file (without the .sig suffix) is intact.  First,
be sure to download both the .sig file and the corresponding tarball.
Then, run a command like this:

  gpg --verify coreutils-8.12.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys 000BEEEE

and rerun the `gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.68.71-af300
  Automake 1.11a
  Gnulib v0.0-5115-ga81348d
  Bison 2.4.588-2f658

===================================================================
NEWS

* Noteworthy changes in release 8.12 (2011-04-26) [stable]

** Bug fixes

  tail's --follow=name option no longer implies --retry on systems
  with inotify support.  [bug introduced in coreutils-7.5]

** 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.

** Portability

  dd once again compiles on AIX 5.1 and 5.2

- -----
also posted as: https://savannah.gnu.org/forum/forum.php?forum_id=6798
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJNtxCCAAoJEH/Z/MsAC+7uLWYQAJSe7I4Gp92cA4m/1SxF1t/S
S8dpD3ay7DWivX6EHFjhrdXu6y/urZjVQAlALNQLBgyzZ+khkwV3KllKWzo6K/Qw
6bU9rF7tbfuzb0/GkOEaFOM3Jp87RzP7Ju31YR/zLx0/0aPGdV/7vGmKmLjdrdoD
0BsW3118cp6i4TT7tFoknNqfDmtBW/B/N8tnpYVBG3UmMK8+UprCdbD63JJ1aiIV
0MP601699T3+iK7N3xSk4c8G6KDV+clCYCxmBiq72IJUDN8qBeuYJ2InVtQZ7ilA
3CG5aLL5sDCBL+lSoy7JtmY9pJ5BbMM+wn/k4jCoqiWjv+cTR1U39RLIG7QQMbg2
7c0sY2LkN2eMCc/mxuCYCMmOtDBkA8eRg1l5bcvRm4SVaMr4OlsmMaLFTfgzxQwh
19OpMlkQya0lmhj/K1k0ONdrox5xvkuIoabYsqOBoNiESaoQkwQNMfJFUltY0pKv
GXQt6o++SQcba+BpFTA+sLbOqahlcpZz3jJG0xoC53X3WKWVPaONou1VE3o8NV4c
7ER727eYq/2/P3wd1IIFP3HpoWPUxxoEEhZb4GqXE7yXCro5vBYn8fV7CKfnivQV
k11mAZRHg9d4Zc+NudxdysSalq84c173Ix9AMqT1iE6sCpiDhzv082k3maLiDZfS
TdzjjS+6yN5h0Kx8H2RT
=iMOO
-----END PGP SIGNATURE-----

_______________________________________________
GNU Announcement mailing list <info-gnu at gnu.org>
https://lists.gnu.org/mailman/listinfo/info-gnu