From owner-freebsd-current@freebsd.org Tue Mar 21 11:26:45 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 C872CD16487; Tue, 21 Mar 2017 11:26:45 +0000 (UTC) (envelope-from julian@elischer.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A136A1A98; Tue, 21 Mar 2017 11:26:45 +0000 (UTC) (envelope-from julian@elischer.org) Received: from Julian-MBP3.local (115-166-5-28.dyn.iinet.net.au [115.166.5.28]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v2LBQc3e035713 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 21 Mar 2017 04:26:41 -0700 (PDT) (envelope-from julian@elischer.org) Subject: Re: effect of strip(1) on du(1) To: "Rodney W. Grimes" , Subbsd References: <201703030031.v230VvIl066398@pdx.rh.CN85.dnsmgr.net> Cc: Peter Jeremy , freebsd-hackers , freebsd-current Current From: Julian Elischer Message-ID: <5688704a-83fe-b5dc-fc21-03fb4a560a4b@elischer.org> Date: Tue, 21 Mar 2017 19:26:32 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <201703030031.v230VvIl066398@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 21 Mar 2017 11:33:31 +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: Tue, 21 Mar 2017 11:26:45 -0000 On 3/3/17 8:31 am, Rodney W. Grimes wrote: >> 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. 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 file's existence. so from that perspective the du is correct.