On 3/3/17 8:31 am, Rodney W. Grimes wrote:
On Fri, Mar 3, 2017 at 2:04 AM, Peter Jeremy <pe...@rulingia.com> wrote:
On 2017-Mar-02 22:29:46 +0300, Subbsd <sub...@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.
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
so from that perspective the du is correct.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"