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

[Jim Meyering]

Paul Eggert wrote:
> On 07/31/2012 11:43 AM, Jim Meyering wrote:
>> It seems a little too far-fetched
>> even for me.
>
> Hah!  I never thought I'd get you to say *that*!
>
> I suppose you're right.  As far as POSIX-conformance goes,
> apps are not required to work "correctly" in the presence
> of mount+unmount syscalls by other processes, and as
> a practical matter it is a rare case where it'd matter.
> Still, it'd be nice to avoid the extra complexity, if
> we could.
>
> It's too bad that there's no reliable way to tell whether
> SEEK_HOLE really works without writing to the file system
> in question (which'd be even worse).
>
>> I do not like it when grep -r mysteriously hangs and makes
>> my system run out of memory.  This really does affect me a couple
>> times per month, at least.
>
> This can happen when files look like text for the first 32 KiB,
> but have big holes later.  If that's the problem, how
> about the following patch?
>
>>From ca6e5ec860cf5a2af060e2a5c8c53d9004ddc131 Mon Sep 17 00:00:00 2001
> From: Paul Eggert <address@hidden>
> Date: Tue, 31 Jul 2012 15:37:40 -0700
> Subject: [PATCH] grep: switch to binary mode when encountering binary data
>  anywhere
>
> * src/main.c (buffer_is_binary): New function.
> (file_is_binary): Use it.  Test for binary data anywhere in the
> file, not just at the start; and when it's encountered, switch
> to binary mode.

Thanks for writing that, but the cost of traversing each buffer one more
time via the added memchr seems like it would be disproportionately high
for this infrequently-seen problem.

Maybe waiting for more wide-spread SEEK_HOLE/SEEK_DATA support is better
after all.