From owner-freebsd-stable@FreeBSD.ORG Sat Aug 6 05:52:01 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 2C552106564A for ; Sat, 6 Aug 2011 05:52:01 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id DA66F8FC0C for ; Sat, 6 Aug 2011 05:52:00 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1QpZni-00089r-Fo>; Sat, 06 Aug 2011 07:51:58 +0200 Received: from e178016095.adsl.alicedsl.de ([85.178.16.95] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1QpZni-0002mp-Cd>; Sat, 06 Aug 2011 07:51:58 +0200 Message-ID: <4E3CD67E.7090201@zedat.fu-berlin.de> Date: Sat, 06 Aug 2011 07:51:58 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110712 Thunderbird/5.0 MIME-Version: 1.0 To: "Patrick M. Hausen" References: <20110802094226.GA93114@icarus.home.lan> <42039B84-D6CE-4780-AA70-8500B1B32036@gsoft.com.au> <4E37CD13.1070402@digsys.bg> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.16.95 Cc: freebsd-stable@freebsd.org, Christian Weisgerber 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: Sat, 06 Aug 2011 05:52:01 -0000 On 08/05/11 21:47, Patrick M. Hausen wrote: > Hi, all, > > Am 05.08.2011 um 17:12 schrieb Christian Weisgerber: >> Daniel Kalchev wrote: >> >>> On 02.08.11 12:46, Daniel O'Connor wrote: >>>> I am pretty sure UFS does not have this problem. i.e. once you >>>> delete/move the files out of the directory its performance would be >>>> good again. >>> UFS would be the classic example of poor performance if you do this. >> "Classic" indeed. UFS dirhash has pretty much taken care of this >> a decade ago. > While dirhash is quite an improvement, it is definitely no silver bullet. > > When I asked Kirk McKusick at last year's EuroBSDCon if having > a six-figure number of files in a single directory was a clever idea > (I just had a customer who ran into that situation), he just smiled > and shook his head. > > The directory in question was the typo3temp/pics directory that > TYPO3 uses to scale images that are part of the website, so they > are handed to the browser in exactly the size they are supposed > to be rendered. The performance impact was quite heavy, because > at some point requests started to pile up, PHP scripts did not finish > in time, fcgi slots stayed used ... most of you will know that scenario. > At some threshold a machine goes from "loaded, maybe a bit slow, > but generally responsive" to "no f*ing way". > > Best regards, > Patrick > I have similar situation here, but with a numerical simulation software, which drops for each timestep of integration a file of all integrated objects. Since the code is adopted and not very clever written in terms of doinf its I/O, I have to deal with this. While performing dynamical high resolution integrations of several hundreds of thousand objects over a time scale of 1 Ga produces even with a larger dump-delta creates a lot of files. making those files bigger results in a situation where they are hard to analyse, so its a tradeoff situation. ZFS and UFS2 perform bad on this situation, UFS2 even more than ZFS, but also ZFS is still a pain in the ass. Oliver