On Tuesday, January 9, 2018 8:59:06 AM CET Paul Eggert wrote:
> Pavel Raiskup wrote:
> > So what about special casing that filesystem, where we can lseek() for
> > holes anyway?
>
> If we can lseek for holes, then why not just do that?
Checking whether lseek() actually works costs some additional
Paul Eggert wrote:
> POSIX does not require that st_nblocks remain constant across any system
> call. It doesn't even require that it remain constant if you merely call
> stat twice on the same file, without doing anything else in between. So
> I agree with you that it's irrelevant whether fsy
Paul Eggert wrote:
> If we can lseek for holes, then why not just do that? We shouldn't need
> special-case code for btrfs per se. Any filesystem where we can lseek for
> holes
> should take advantage of that optimization.
This is what star uses since 13 years ;-)
Jörg
--
EMail:jo...@schi
Pavel Raiskup wrote:
> On Tuesday, January 9, 2018 8:59:06 AM CET Paul Eggert wrote:
> > Pavel Raiskup wrote:
> > > So what about special casing that filesystem, where we can lseek() for
> > > holes anyway?
> >
> > If we can lseek for holes, then why not just do that?
>
> Checking whether lseek(
> Paul Eggert wrote:
>
>> POSIX does not require that st_nblocks remain constant across any system
>> call. It doesn't even require that it remain constant if you merely call
>> stat twice on the same file, without doing anything else in between.
The real question is then:
What is the most e
On 01/09/2018 09:02 AM, Tim Kientzle wrote:
So is there some other way to quickly identify sparse files so we can avoid the
SEEK_HOLE scan for non-sparse files?
Nothing that's at all portable, no.
On 01/09/2018 01:38 AM, Joerg Schilling wrote:
If POSIX would allow such unexpected behavior, this would have been documented.
I'm afraid we'll just have to agree to disagree here. Even if you expect
a particular behavior, it's not the behavior that I expect nor is it the
behavior that we act
Mark H Weaver writes:
> I don't expect any of this to convince you, but it is most likely the
> last message I will write in this "debate" between you and the rest of
> the world. Instead, I will focus on fixing the bug.
I apologize for losing my patience here. This last paragraph was in
poor t
>From da922703282b0d3b8837a99a9c7fdd32f1d20d49 Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Tue, 9 Jan 2018 20:16:14 -0500
Subject: [PATCH] Remove nonportable check for files containing only zeroes.
This check benefitted only one unlikely case (large files containing
only zeroes, on systems
