Re: Knoppix to Debian - A Roadmap what needs to be done

[Fabian Franz <FabianFranz@gmx.de>]

Am Donnerstag, 15. April 2004 18:04 schrieb Goswin von Brederlow:
> Hi,
>
> Fabian Franz <FabianFranz@gmx.de> wrote:
> > Am Donnerstag, 15. April 2004 01:19 schrieb Sergio Talens-Oliag:
> > > El Wed, Apr 14, 2004 at 11:12:31PM +0200, Fabian Franz escribió:
> > > > 3. There are currently 2 build processes for knoppix:
> > > >
> > > > - Klaus build scripts, which are speed optimized and have the
> > > > need to boot into the system, then master from there.
> > > > - chroot, make some changes, clean up, master.
> > > >
> > > > The first scripts have the advantage that they do everything
> > > > necessary to have a clean boot-cd. Yes, there are scripts that
> > > > can do that and yes they are available from web (a bit outdated
> > > > (for the still to be released 3.4), but I'm almost sure Klaus
> > > > would publish his new ones in CVS)
> > >
> > >   I think this is the aproach we all were talking about, I don't
> > >   know why the booting is needed, but the rest is what we were
> > >   talking about.
> >
> > The booting is needed to speed up the booting after with a sortlist,
> > rather tricky but very performant.
>
> Can you elaborate that a bit? What is speed up? What is listed and
> sorted?

Ok, I'll explain shortly and then go back to get my todo list done, to be able 
to have time for this project. (user-mode splash is the last item on it ;-) )

Knoppix uses cloop, which is a compress looped ISO-file.

ISOs have one _big_ advantage. They have really fast access times and the 
files on it can be sorted by mkisofs.

The trick Klaus now uses is to touch mkisofs.timestamp, then reboot and do a 
find on the access times. (Start OpenOffice and other big programs - that 
makes a difference - really)

This creates a sortlist (+some sorted things like /bin first) that can be used 
by mkisofs and create a sorted image.

Btw. my tests with lvm2+snapshots were only frustratiing. I did not have the 
time yet to write it to you. 

First: Need of writable medium (ext3).
Second: Snapshot writes only as much files as space was available on the 
original image. (df shows this nicely) And if I have not read the 
kernel-source wrong, overlay filesystems on blocklayer can not work so 
easily ...

Third: Kernel crash when too much data was written + data corruption. (Not 
possible to clean-up written data)

Fourth: I found no possibility to use _normal_ dm-tools to setup the snapshots 
and dmsetup is not very powerful. (Not possible to move the snapshot and so 
on)

To clear this up: I really like the idea of being able to have writable 
snapshots, but I don't see how lvm2 can do this. 

I really thought this was the solution and did even write in an article I 
wrote for "Linux Intern" that that was the future. (including your name ;-) )

I think this needs to be done on filesystem layer, but that is another 
story ...

cu

Fabian