effect of strip(1) on du(1)

[Julian Elischer]

On 3/3/17 8:31 am, Rodney W. Grimes wrote:
>> On Fri, Mar 3, 2017 at 2:04 AM, Peter Jeremy <peter at rulingia.com> wrote:
>>> On 2017-Mar-02 22:29:46 +0300, Subbsd <subbsd at gmail.com> wrote:
>>>> During some interval after strip call, du will show 512B for any file.
>>>> If execute du(1) after strip(1) without delay, this behavior is reproduced 100%:
>>> What filesystem are you using?  strip(1) rewrites the target file and du(1)
>>> reports the number of blocks reported by stat(2).  It seems that you are
>>> hitting a situation where the file metadata isn't immediately updated.
>>>
>>> --
>>> Peter Jeremy
>>
>> Got it. My filesystem is ZFS. Looks like when ZFS open and write data
>> to file, we get wrong number of blocks during a small interval after
>> writing. Thanks for pointing this out!
> 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.

actually it's all in how you look at it.
Due to the way ZFS is doing the work and the metadata transitions, 
that amount of storage is actually directly attributable to that 
file's existence.
so from that perspective the du is correct.