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. -AlanReceived 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