> 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. -- Rod Grimes rgrimes_at_freebsd.orgReceived on Thu Mar 02 2017 - 23:32:04 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:10 UTC