From owner-freebsd-fs@FreeBSD.ORG Wed Mar 20 13:02:07 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D0BE8912 for ; Wed, 20 Mar 2013 13:02:07 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 6340C6FA for ; Wed, 20 Mar 2013 13:02:07 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UIIea-0008He-Nl for freebsd-fs@freebsd.org; Wed, 20 Mar 2013 14:02:05 +0100 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UIIea-00047h-Ge for freebsd-fs@freebsd.org; Wed, 20 Mar 2013 14:02:04 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-fs@freebsd.org Subject: Re: FreBSD 9.1 and ZFS v28 performances References: <1DD6360145924BE0ABF2D0979287F5F4@multiplay.co.uk> <51474F2F.5040003@contactlab.com> <51475267.1050204@contactlab.com> <514757DD.9030705@contactlab.com> <4930f6fddf6a995051bc6554d1a6a6b7@sys.tomatointeractive.it> <51499351.1040406@digsys.bg> <20130320124501.GA60926@neutralgood.org> Date: Wed, 20 Mar 2013 14:02:04 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <20130320124501.GA60926@neutralgood.org> User-Agent: Opera Mail/12.14 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: ++++++++ X-Spam-Score: 8.2 X-Spam-Status: Yes, score=8.2 required=5.0 tests=BAYES_40, IN_PBL_AND_BAYES_40, RCVD_IN_SBL autolearn=disabled version=3.3.1 X-Spam-Flag: YES X-Scan-Signature: 76f3589a93270604ea078d468a2051b3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 13:02:07 -0000 On Wed, 20 Mar 2013 13:45:01 +0100, wrote: > On Wed, Mar 20, 2013 at 01:32:19PM +0100, Ronald Klop wrote: >> On Wed, 20 Mar 2013 11:45:37 +0100, Daniel Kalchev >> wrote: >> >> Well, after changing the recordsite property, I copied the file from >> an >> >> UFS partition (using cp -Rp): this should use recordsize=16k, right? >> > >> > Perhaps, if you delete the file, or preferably the entire ZFS dataset >> > first. Copying an file over another existing, does not change anything >> > with the destination file except it's contents and modification times. >> > As is always with changing settings, it is safer to just create the >> > entire data set from scratch, with the new settings. >> > >> > Daniel >> >> ZFS never overwrites contents of a files. It always allocates new >> blocks. > > True but not really relevant. > > Taking an existing file, truncating it to length zero, and then putting > data into it results in the same file having different contents. But > deleting the existing file, creating a new file, and putting data into it > gives you (like I said) a new/different file. This is true with both UFS > and ZFS. > > Applications don't care that ZFS does COW under the hood. Applications > care that the observed behavior of ZFS be similar to UFS. > It is relevant. After changing the recordsize all new blocks will get the new recordsize. The discussion was not about if a file is the same one or not. It is about if the recordsize changes. And recreating the volume/pool is not needed for that. Ronald.