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

From: Alan Somers <asomers_at_freebsd.org>
Date: Thu, 2 Mar 2017 18:30:32 -0700
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.

-Alan
Received on Fri Mar 03 2017 - 00:30:33 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:10 UTC