Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Jan 2004 11:52:51 -0800
From:      Tim Kientzle <kientzle@acm.org>
To:        Robert Watson <rwatson@freebsd.org>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: Request for Comments: libarchive, bsdtar
Message-ID:  <40059E13.2020609@acm.org>
In-Reply-To: <Pine.NEB.3.96L.1040114142135.49872F-100000@fledge.watson.org>
References:  <Pine.NEB.3.96L.1040114142135.49872F-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40059E13.2020609>