On 3/2/17 5:30 PM, Alan Somers wrote:
On Thu, Mar 2, 2017 at 6:12 PM, Ngie Cooper <yaneurab...@gmail.com> wrote:
On Thu, Mar 2, 2017 at 4:31 PM, Rodney W. Grimes
<freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
Even if that is the case file system cache effects should NOT be
visible to a userland process.   This is NOT as if your running
2 different processing beating on a file.  Your test cases are
serialially syncronous shell invoked commands seperated with
&& the results should be exact and predictable.

When strip returns the operation from the userland perspecive
is completed and any and all processeses started after that
should have the view of the completed strip command.

This IS a bug.
Would the same statement necessarily apply if the filesystem was
writing things asynchronously to the backing storage?
du(1) is using fts_read(3), which is based on the stat(2) information.
The OpenGroup defines st_blocksize as "Number of blocks allocated for
this object."  In the case of ZFS, a write(2) may return before any
blocks are actually allocated.  And thanks to compression, gang
blocks, and deduplication, at this point it's not even possible for
ZFS to know how many blocks it will need to allocate.  I think
st_blocksize should be interpreted as a "best effort" output.  Just
like df(1), you can't rely on du's output to be mathematically precise
in any way.  I certainly don't see any way to fix it besides doing
something like an fsync(2) before getting stat information, and we
certainly don't want to do that.

Try adding an fsync(1) to the file before running du(1) on it.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to