Date: Mon, 08 Aug 2011 14:11:18 +0300 From: Daniel Kalchev <daniel@digsys.bg> To: freebsd-stable@freebsd.org Subject: Re: ZFS directory with a large number of files Message-ID: <4E3FC456.8040508@digsys.bg> In-Reply-To: <20110806062415.GB88904@in-addr.com> References: <CAJGy1F0d7jeyaFuNdXe%2BucTL2r7R4suCyu8xG7WRHenMFZH-6g@mail.gmail.com> <20110802094226.GA93114@icarus.home.lan> <42039B84-D6CE-4780-AA70-8500B1B32036@gsoft.com.au> <4E37CD13.1070402@digsys.bg> <j1h18t$jh1$1@lorvorc.mips.inka.de> <BA47D829-B2E3-419B-AC50-FD3F6FCC54EF@punkt.de> <6E45CE57-491E-4077-B14C-751C73647EFC@gsoft.com.au> <4E3CBB74.9020208@FreeBSD.org> <20110806062415.GB88904@in-addr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E3FC456.8040508>