From owner-freebsd-stable@FreeBSD.ORG Mon Aug 8 11:11:29 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41C14106567B for ; Mon, 8 Aug 2011 11:11:29 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id BE6C38FC14 for ; Mon, 8 Aug 2011 11:11:28 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p78BBIUb038662 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 8 Aug 2011 14:11:24 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4E3FC456.8040508@digsys.bg> Date: Mon, 08 Aug 2011 14:11:18 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20110802094226.GA93114@icarus.home.lan> <42039B84-D6CE-4780-AA70-8500B1B32036@gsoft.com.au> <4E37CD13.1070402@digsys.bg> <6E45CE57-491E-4077-B14C-751C73647EFC@gsoft.com.au> <4E3CBB74.9020208@FreeBSD.org> <20110806062415.GB88904@in-addr.com> In-Reply-To: <20110806062415.GB88904@in-addr.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ZFS directory with a large number of files X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 11:11:29 -0000 On 06.08.11 09:24, Gary Palmer wrote: > Its been quite a while since I worked on the filesystem stuff in any > detail but I believe, at least for UFS, it doesn't GC the directory, > just truncate it if enough of the entries at the end are deleted to > free up at least one fragment or block. This was my point indeed. If you empty a directory or remove files form the end of the directory is it truncated, this is not really a GC, but rather a shortcut. I guess the reason why it does not use GC is because of concurrency/locking reasons. Or maybe the code was just not written yet. But with ZFS this should be much easier to implement. If it is the same in Solaris, then it is not done so far... But then, the promise made by ZFS is to provide constant directory access timing. I am just wondering.. does implementing such garbage collection merit a new ZFS filesystem version? Daniel