Date: Fri, 3 Mar 2017 00:36:00 -0800 From: Alfred Perlstein <alfred@freebsd.org> To: Alan Somers <asomers@freebsd.org>, Ngie Cooper <yaneurabeya@gmail.com> Cc: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.cn85.dnsmgr.net>, Subbsd <subbsd@gmail.com>, Peter Jeremy <peter@rulingia.com>, freebsd-hackers <freebsd-hackers@freebsd.org>, freebsd-current Current <freebsd-current@freebsd.org> Subject: Re: effect of strip(1) on du(1) Message-ID: <9fb69e17-cb7f-5f04-aeb3-914ba58ddab4@freebsd.org> In-Reply-To: <CAOtMX2hbvnDqBWry4GNX=9-1nqEgcF8PwFZLQS_EaX2nkZsPRQ@mail.gmail.com> References: <CAFt_eMom-C68Fo4NR8HVqPBUwKTKYUvCy2seXDg3hzOOU_f=Vw@mail.gmail.com> <201703030031.v230VvIl066398@pdx.rh.CN85.dnsmgr.net> <CAGHfRMCVQdD4uULOPZsNxrrEZ%2BNAtJ6f1qMdSc8xtCHmwEfYMg@mail.gmail.com> <CAOtMX2hbvnDqBWry4GNX=9-1nqEgcF8PwFZLQS_EaX2nkZsPRQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/2/17 5:30 PM, Alan Somers wrote: > On Thu, Mar 2, 2017 at 6:12 PM, Ngie Cooper <yaneurabeya@gmail.com> wrote: >> On Thu, Mar 2, 2017 at 4:31 PM, Rodney W. Grimes >> <freebsd-rwg@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. > > Try adding an fsync(1) to the file before running du(1) on it. -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9fb69e17-cb7f-5f04-aeb3-914ba58ddab4>