Date: Thu, 2 Mar 2017 22:13:52 -0800 (PST) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> To: Ngie Cooper <yaneurabeya@gmail.com> Cc: 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: <201703030613.v236DqUN067774@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <CAGHfRMCVQdD4uULOPZsNxrrEZ%2BNAtJ6f1qMdSc8xtCHmwEfYMg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ Charset UTF-8 unsupported, converting... ] > 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? Caching should^h^h^h^hshall be transparent to a userland process. Are you actually advocating that a userland process should be able to see that zfs is write caching meta data? The strip(1) command has completed and exited, pola dictates that anything I asked strip(1) to do be reflected in all commands or system calls executed after it. Anything else would be a bug. > Thanks, > -Ngie -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201703030613.v236DqUN067774>