From owner-freebsd-current@FreeBSD.ORG Fri May 21 07:36:29 2004 Return-Path: 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 B130616A4CE for ; Fri, 21 May 2004 07:36:29 -0700 (PDT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D4A343D31 for ; Fri, 21 May 2004 07:36:29 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 6786 invoked from network); 21 May 2004 14:35:29 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 21 May 2004 14:35:29 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i4LEZLKS076984; Fri, 21 May 2004 10:35:21 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org, jesse@wingnet.net Date: Fri, 21 May 2004 10:35:55 -0400 User-Agent: KMail/1.6 References: <20040520185047.GA98339@sirius.firepipe.net> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405211035.55975.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx Subject: Re: GEOM portable filesystem abstraction? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Fri, 21 May 2004 14:36:29 -0000 On Friday 21 May 2004 09:37 am, Jesse Guardiani wrote: > Will Andrews wrote: > > On Thu, May 20, 2004 at 02:44:06PM -0400, Jesse Guardiani wrote: > >> It seems like GEOM functions as a bit of a disk > >> abstraction layer in FreeBSD. Would it be possible > >> to port the GEOM subsystem as a loadable kernel > >> module to Linux (and perhaps other OSes) to > >> facilitate pluggable, portable filesystem code? > > > > GEOM is below the filesystem layer and thus wouldn't help you > > with the filesystem portability issue. > > Well, that's kinda the point. If you want to port filesystems > to multiple architectures/OSes, then you need a common underlying > infrastructure. I was thinking GEOM might be it. Plus, GEOM > makes GBDE encrypted volumes possible. Filesystems are really in a sandwich of layers. For example, on typical VFS UNIXs, you have this: system calls | vnode layer | file system | dev_t device On FreeBSD and other VFS UNIXs with a unified buffer cache it gets a bit more complicated as the vnode/file system layers talk to VM, which calls back into the vnode/file system layers, etc. GEOM is an abstraction for the dev_t layer of that tree. It is not an abstraction for the VM system or for the way that requests are made of the file system by the rest of the kernel (i.e. syscalls, VM, etc.). GEOM is just one piece of the puzzle and is not enough of the puzzle to provide a completely portable file system API. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org