From owner-svn-src-all@FreeBSD.ORG Sat Dec 6 21:00:37 2014 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF55D6B4; Sat, 6 Dec 2014 21:00:37 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6DB75FF5; Sat, 6 Dec 2014 21:00:37 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 561E016A401; Sat, 6 Dec 2014 22:00:33 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kojEh7_drAMl; Sat, 6 Dec 2014 22:00:23 +0100 (CET) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id AF96D16A402; Sat, 6 Dec 2014 21:49:16 +0100 (CET) Message-ID: <54836BCC.2080707@digiware.nl> Date: Sat, 06 Dec 2014 21:49:16 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Andriy Gapon , d@delphij.net, Xin LI , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r273060 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs References: <201410132039.s9DKdpmh055573@svn.freebsd.org> <546F57B1.2020602@FreeBSD.org> <546F9FC3.10402@delphij.net> <5474540D.2000607@FreeBSD.org> In-Reply-To: <5474540D.2000607@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 21:00:37 -0000 On 25-11-2014 11:03, Andriy Gapon wrote: > On 21/11/2014 22:25, Xin Li wrote: >> On 11/21/14 07:18, Andriy Gapon wrote: >>> On 13/10/2014 23:39, Xin LI wrote: >>>> Author: delphij Date: Mon Oct 13 20:39:51 2014 New Revision: >>>> 273060 URL: https://svnweb.freebsd.org/changeset/base/273060 >>>> >>>> Log: Use write_psize instead of write_asize when doing >>>> vdev_space_update. Without this change the accounting of L2ARC >>>> usage would be wrong and give 16EB free space because the number >>>> became negative and overflows. >>>> >>>> Obtained from: FreeNAS (issue #6239) >> >>> First, a link to the issue would be more convenient for reviewers. >>> Here it is https://bugs.freenas.org/issues/6239 >> >>> Then, I would like to see a technical explanation for this change. >>> I could not find any explanation here or in the FreeNAS issue or in >>> the FreeNAS commit. >> >>> As far as I can see, all calls to vdev_space_update() in the ARC >>> code are passed l2hdr->b_asize or a sum of b_asize fields of >>> multiple buffers. Thus, I am really surprised with this change and >>> would like to see reasoning behind it. >> >> Hmm I think you are right that my change doesn't make sense but I >> can't remember the details either and suggests there is some other >> issues that was covered up by this. > > Maybe you have some other changes in FreeNAS and the change in question is > supposed to work along with them? > > Meanwhile, perhaps the discussed commit needs to be reverted? > >> It looks like that I was confused because the L2ARC clock hand >> advances by buf_p_sz (unrelated but it should really be called >> buf_a_size) and the way we calculate allocated L2ARC free. > > Agree about 'a' vs 'p'. And, BTW, we have some related changes in ClusterHQ > that I will upstream. > Not sure how this got resolved but I immediately recognise some of this since I run into this on one of my volumes. These are 2 ssd caches on a raidz2 pool, and they are certainly not 16EB. ........... cache - - - - - - diskid/DISK-S1ANNSADB75814Wp3 109G 187G 16.0E - 0% 172% diskid/DISK-S1ANNSADB75819Ep3 109G 166G 16.0E - 0% 152% --WjW