From owner-freebsd-current@FreeBSD.ORG Mon Jun 6 05:06:24 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9F5216A41C; Mon, 6 Jun 2005 05:06:24 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from sp.dominia.org (efnet-math.org [69.60.109.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D89D43D53; Mon, 6 Jun 2005 05:06:24 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.1.12] (63-170-138-118.cst-sg.blacksburg.ntc-com.net [63.170.138.118]) (authenticated bits=0) by sp.dominia.org (8.13.1/8.13.1) with ESMTP id j56562pU018062 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 6 Jun 2005 01:06:20 -0400 In-Reply-To: <42A3D6CF.2000504@samsco.org> References: <82ACAD58-B179-44E2-852F-60F25C0BBBC1@FreeBSD.org> <20050606033145.GA80739@www.portaone.com> <42A3D6CF.2000504@samsco.org> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0A6C1F19-A734-4EC8-BE97-2D000D189968@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Suleiman Souhlal Date: Mon, 6 Jun 2005 01:05:51 -0400 To: Scott Long X-Mailer: Apple Mail (2.730) Cc: Maxim Sobolev , current@FreeBSD.org, fs@FreeBSD.org Subject: Re: [PATCH] IFS: Inode FileSystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2005 05:06:24 -0000 Hi, On Jun 6, 2005, at 12:53 AM, Scott Long wrote: > Maxim Sobolev wrote: > >> Are there any real users of this FS? If my memory serves, >> Adrian's plan was to add IFS support into the squid. I >> wonder if it had happened and whether or not it actually >> provides any real performance benefit. >> -Maxim >> > > IFS is centered around the observation that most apps already keep a > metamapping of 'filename ABC = data XYZ', where the filename is really > nothing more than a unique identifier for the data. Expressive > filenames and file hierachies are useful for humans, but matter > little to computers. The name "squid/cache/a/b/abc" has as much > meaning to a computer as the name "12345" (which might be the inode > number of the file). So taking this into account, you can strip > out all the overhead of recursive namei lookups, directory data reads, > directory hashing, etc, and just use the inode number directly as the > identifier for inodes. Looking up by inode is a O(1) operation > consisting of merely using the number to index into a inode array in a > particular cylinder group. It's a huge win for CPU overhead in the > filesystem, especially when we start talking about increasing the size > of m_links field and possibly going to 64-bit inode numbers. Talking about going to 64-bit inode numbers, how would we deal with the change in stat(2)? -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org