Re: effect of strip(1) on du(1)

> On Thu, Mar 2, 2017 at 6:12 PM, Ngie Cooper <yaneurabeya_at_gmail.com> wrote:
> > On Thu, Mar 2, 2017 at 4:31 PM, Rodney W. Grimes
> > <freebsd-rwg_at_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?
> > Thanks,
> > -Ngie
> 
> 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.

My gut tells me that this is gona cause problems, is it ONLY
the st_blocksize data that is incorrect then not such a big
problem, or are we returning other meta data that is wrong?

Waving hands over this report as async write behind meta
data issues is not making sure we dont have a more serious
problem.

My expectactions of executing a stat(2) call on a file would
be that the data returned is valid and stable.  I think almost
any program would expect that.

-- 
Rod Grimes                                                 rgrimes_at_freebsd.org