Andreas Dilger wrote:
> Given that calling SEEK_HOLE is also going to have some cost, my suggestion
> would be to ignore st_blocks completely for small files (size < 64KB) and
> just read the file in this case, since the overhead of reading will probably
> be about the same as checking if any blo
Andreas Dilger wrote:
> > POSIX does not require you to call fsync() before you are able to get the
> > expected result from stat()
> >
> > If POSIX did make such assumptions, it would document then. The fact that
> > there is no related text in POSIX is sufficient to prove what POSIX expects.
>
Andreas Dilger wrote:
> That means SEEK_HOLE is NOT available in RHEL 6.x kernels, which are still
> in fairly widespread (though declining) use. I'd prefer that the heuristic
> for sparse files without SEEK_HOLE not be removed completely, but I do think
> that it needs to be fixed for the small
On Jan 10, 2018, at 5:05 AM, Dominique Martinet
wrote:
>
> Hi,
>
> Pavel Raiskup wrote on Wed, Jan 10, 2018 at 12:50:06PM +0100:
>>> This check benefitted only one unlikely case (large files containing
>>> only zeroes, on systems that do not support SEEK_HOLE)
>>
>> It drops the optimization e
On 01/18/2018 02:33 AM, Joerg Schilling wrote:
Returning a value for st_blocks, that changes with the phases of the moon while
the content of that file is not changed is another unexpected behavior.
Not at all. It's completely expected nowadays, for the same reason that
invoking statvfs twice
On Jan 17, 2018, at 9:49 PM, Tim Kientzle wrote:
>> On Jan 17, 2018, at 1:09 PM, Andreas Dilger wrote:
>>
>>> So is there some other way to quickly identify sparse files so we can avoid
>>> the SEEK_HOLE scan for non-sparse files?
>>
>> Given that calling SEEK_HOLE is also going to have some c
