Re: Knoppix to Debian - A Roadmap what needs to be done
Fabian Franz <FabianFranz@gmx.de> writes:
> 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.
Ahh. Thats nice. But Debix is using a normal writeable FS so that
won't apply to me.
> 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).
Beter not use a journaling FS. Waste of space since everything is
volatile anyway. No fsck ever.
> 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 ...
One could grow the filesystem. Not sure if ext2 or xfs growing can be
done with minimal changes to the existing image (minimum chages to be
stored in ram). For now I just made the filesystem as big as I
needed. With cloop a lot of empty space in the compressed image should
not realy matter.
> Third: Kernel crash when too much data was written + data corruption. (Not
> possible to clean-up written data)
If you ran out of ram thats a problem. I was thinking about writing a
small applet that would warn before it happens. But with todays ram
sizes you can write a lot of 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)
dmsetup is exactly the tool for it. You just have to load the tables
that reflect the mirror. The syntax is not documented in the manpage
but realy easy. You can create a snapshot with lvm and then look at
the resulting mappings with dmsetup.
> 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
A filesystem could free up ram when files are deleted. Would be much
better but who will write it?
MfG
Goswin
Reply to: