Re: SEEK_HOLE defined but useless on linux-3.4+/ext4 [Re: small ascii files can be sparse

[Jim Meyering]

Eric Blake wrote:
> On 07/30/2012 12:05 PM, Jim Meyering wrote:
>> Paul Eggert wrote:
>>> On further thought, the heuristic is also incorrect for file
>>> systems that compress their data.  So I installed this further
>>> patch.
>>>
>>> Oh, well.  At least the code is simpler now.  Simple and slow
>>> is better than complicated and fast and occasionally wrong.
>> ...
>>> Subject: [PATCH] grep: don't falsely report compressed text files as binary
>>>
>>> * NEWS: Document this.
>>> * src/main.c (file_is_binary): Remove the heuristic based on
>>> st_blocks, as it does not work for compressed file systems.
>>> On Solaris, it'd be cheap to test whether the file system is known
>>> to be uncompressed, which allow the heuristic, but Solaris has
>>> SEEK_HOLE so there's little point.
...
>> Without the st_blocks-based heuristic, grep's big-hole test now fails
>> (exhausts memory and exits with status 2) on an ext4 file system with
>> a recent linux kernel.
>> That happens because while SEEK_HOLE and SEEK_DATA are now defined,
>> the kernel's ext4 lseek/SEEK_HOLE support is just a stub that simply
>> returns the length of the file.
>
> Does FIEMAP give any better answer for ext4, while waiting for newer
> kernels to properly implement SEEK_HOLE?

I am inclined to avoid using the FIEMAP ioctl here because:

  - this particular heuristic can affect grep's exit status,
      e.g., when running grep on a sparse image

  - this ioctl is usable only with relatively new linux kernels

  - the interface is cumbersome (putting it mildly)

Here, it may be enough to use the old heuristic, but treat a file
as non-sparse when it has st.st_size <= ST_BLKSIZE(st).

The arguments for switching from ext4 to btrfs are adding up...