From owner-freebsd-current@freebsd.org Fri Mar 3 00:32:04 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9A85CF6EE2; Fri, 3 Mar 2017 00:32:04 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7594818D1; Fri, 3 Mar 2017 00:32:03 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v230VxFY066399; Thu, 2 Mar 2017 16:31:59 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v230VvIl066398; Thu, 2 Mar 2017 16:31:57 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201703030031.v230VvIl066398@pdx.rh.CN85.dnsmgr.net> Subject: Re: effect of strip(1) on du(1) In-Reply-To: To: Subbsd Date: Thu, 2 Mar 2017 16:31:57 -0800 (PST) CC: Peter Jeremy , freebsd-hackers , freebsd-current Current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Fri, 03 Mar 2017 01:00:18 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 00:32:04 -0000 > On Fri, Mar 3, 2017 at 2:04 AM, Peter Jeremy wrote: > > On 2017-Mar-02 22:29:46 +0300, Subbsd 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@freebsd.org