[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Integrate Knoppix in Debian (was: Re: Debian Enterprise?)



Matt Zimmerman <mdz@debian.org> writes:

> On Wed, Nov 26, 2003 at 06:18:03PM +0100, Goswin von Brederlow wrote:
> 
> > Matt Zimmerman <mdz@debian.org> writes:
> > > So am I to understand that you plan to use device-mapper snapshots in order
> > > to provide copy-on-write at the block device level in order to implement
> > > this?  If so, this is interesting.  I assume you will use a RAM disk for
> > > writable storage?  What filesystem will you use?
> > 
> > Yes, thats exactly how it works. One device for the loopback file, one
> > for the ramdisk/tmpfs storage and a copy-on-write snapshot combining
> > those two into the real root device.
> > 
> > Recent kernels allow using loopback files on tmpfs. Older kernels need
> > to use one or more ramdisks.
> 
> Hmm, so a loopback file on tmpfs could be sparsely allocated, and tmpfs
> would dynamically allocate memory as it grew.  Very nice.

Yep, ramdisk is allocated by demand too.

> > As filesystem I only used ext2. But device mapper provides a normal block
> > device like any other. Only think to note is that using a journaled
> > filesystem like ext3, xfs or reiserfs might not be the best idea since the
> > journal will fill up 32 MB (or whatever the fs has) of ram with no
> > benefit.
> 
> Correct, a journal does not make sense.  I do wonder, though, whether
> particular filesystems would attempt to minimize resource consumption in a
> situation like this, by reusing deleted blocks rather than allocating new
> ones, something opposite to what jffs2 does.

I have an item on my TODO list to add a mount (or tune2fs) option to
ext2 to allways reuse the block with the lowest number. That way it
would reuse a previously used and freed block instead of allocating a
fresh one.

Of cause genext2fs would have to use the same allocation scheme so it
doesn't leave holes at the start.

MfG
        Goswin



Reply to: