From owner-freebsd-arch@FreeBSD.ORG Wed Jan 14 11:52:54 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CF0F16A4CE; Wed, 14 Jan 2004 11:52:54 -0800 (PST) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADC6D43D39; Wed, 14 Jan 2004 11:52:52 -0800 (PST) (envelope-from kientzle@acm.org) Received: from acm.org ([66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id i0EJqqkX074485; Wed, 14 Jan 2004 11:52:52 -0800 (PST) (envelope-from kientzle@acm.org) Message-ID: <40059E13.2020609@acm.org> Date: Wed, 14 Jan 2004 11:52:51 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: Request for Comments: libarchive, bsdtar X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 19:52:54 -0000 Robert Watson wrote: > On Tue, 13 Jan 2004, Tim Kientzle wrote: > >>I've been working on ... a library that can read/write tar archives. > > ... a read-only tarfs for use as a root file system ... > ... our current release build ... requires privilege so that it can ... manage md > devices and file system images. Just being able to use a tarball instead > of a UFS image would go a long way... > > I know NetBSD has a neat tool to create file systems from userspace > without privilege ... An interesting idea. A couple of relevant observations: 1) tar/gzip archives are streaming archives. There is no simple means for random access. Using a tar/gzip file as a filesystem would require reading through the archive to find each file. With careful design, this might not be a performance problem, but it does limit the applications somewhat. 2) Uncompressed tar archives can provide random access if you're willing to scan the archive and build an in-memory directory when you mount it. This is pretty easy to do, especially if you restrict yourself to basic 'ustar' archives. 3) An alternative would be to build a tool for creating/manipulating a UFS image, along the lines of mtools or mkisofs. Just the basics: an md image doesn't need UFS2 extended attributes or softupdates, so it shouldn't be that hard. To be honest, trying to share code with the kernel may be more work than it's worth. Such a tool may also be able to optimize the size of the resulting FS image (stat everything, calculate the FS layout, then have a second pass that actually writes the resulting FS). Sounds like a good project for an enthusiastic college student. I'm certain someone out there is taking a filesystems class and would be interested in taking a crack at this. Point them at some good UFS documentation and see what happens. 4) Of course, mkisofs/mkhybrid exists. Why not use cdroot? It may seem a bit peculiar to load a CDROM image into RAM from a series of floppy disks, but all of the necessary tools and support code already exist. Tim