Re: [Bug-tar] Detection of sparse files is broken on btrfs

[Andreas Dilger]

> On Jan 8, 2018, at 11:50 AM, Joerg Schilling <address@hidden> wrote:
> 
> Paul Eggert <address@hidden> wrote:
> 
>> On 01/08/2018 09:41 AM, Joerg Schilling wrote:
>>> POSIX explains that st_blocks counts in units of DEV_BSIZE.
>> 
>> That's not required by the standard. It's merely a comment in the
>> <sys/stat.h> rationale "Traditionally, some implementations defined the
>> multiplier for /st_blocks/ in /<sys/param.h>/
> 
> My impression is that you look at the wrong things.
> 
> POSIX does not require you to call fsync() before you are able to read written
> data from a file.

Sure, but nobody said anything about data not being consistent for reads
without a prior fsync.

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

I don't agree with your extrapolation at all.  You're saying that everything
POSIX doesn't document must be forbidden, which is a big stretch.

This would make filesystems that compress data in the background, or migrate
between different storage tiers (e.g. flash to HDD with a different sector
or block size) to be non-compliant, just because the st_blocks value is
changing from one stat call to the next.

My conclusion would be exactly the opposite of yours.  The fact that there
is no text that documents that st_blocks must remain constant implies that
it does NOT need to remain constant from one call to the next.  If anything
were to be added to the spec, it should only say that st_blocks should be
non-zero for files that contain data.

> So the real problem is not what exact value you may expect but rather whether
> btrfs behaves inconsistent because you get different results after calling
> fsync().

Cheers, Andreas

signature.asc
Description: Message signed with OpenPGP