> On Jan 8, 2018, at 11:50 AM, Joerg Schilling > <joerg.schill...@fokus.fraunhofer.de> wrote: > > Paul Eggert <egg...@cs.ucla.edu> 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