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

On 3/2/17 5:30 PM, Alan Somers wrote:
> 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.
>
>
Try adding an fsync(1) to the file before running du(1) on it.

-Alfred