El Fri, Apr 16, 2004 at 12:04:12PM +0200, Goswin von Brederlow escribió:
> Sergio Talens-Oliag <sto@debian.org> writes:
> > Well, I think the main problem with this is that I'm always thinking
> > that the LiveCD is a system that always has to do the hardware
> > detection, autoconfigure some services and is limited by the use of
> > a read-only root filesytem that makes some programs unusable, but a HD
> > installation does not have those limitations.
> >
> >> One main design trick of Debix is that all the live-cd specials are
> >> contained _just_ in the initial ramdisk (+ some files on the cd for
> >> space reasons). The ramdisk finds (when I get it finished) the CD (usb
> >> stick, CF card, harddisk install, whatever medium) and sets that up as
> >> a writeable snapshot (COW to ram) with device-mapper.
> >
> > I agree on having all the specials on the ramdisk.
> >
> > My proposal about config files only for the LiveCD is because I'm
> > always thinking about a read-only root filesystem, while you think
> > about it as a writable one.
>
> I use setups with read-only / and /usr myself and config files used by
> live-cd packages should be moved to /var/ and other software
> configured to use them. Policy dictates so anyway and it works for all
> cases: normal debian, live-cd, read-only /.
Yes, I agree on moving config files modified at runtime to '/var'.
The files I wanted under '/etc' are the configuration files that are
going to be used by the LiveCD but are not going to be modified once
the ISO is ready (i. e. a different set of scripts for a given
runlevel).
But thinking about it, those files should be generated or modified by
the livecd generation tools using user editable config files (i.e.
files under '/etc/debian_livecd/', that can be copied to the LiveCD
root filesystem) and doesn't matter if they are generated and copied
to the livecd's '/etc' before we create the ISO or are generated at
runtimeand stored under '/var/etc/' as long as the programs that
need them are able to use them at runtime.
> > I like the idea of writable snapshots, but I've never used LVM nor the
> > device-mapper and I don't know which requiriments or limitations does
> > it have ... can you give me some pointers to documentation?
>
> It requires the device-mapper patches for the kernel. The snapshort
> support is still not present in the vanilla kernel. After that you
> only need a few userspace tools.
>
> As limitations go one could name the following:
>
> - When a snapshot is full all hell breaks loose. Writes fail, changes
> will get lost, software will fail.
Sounds scary, it means that on low memory systems things can break
really fast, well, depending on the services and programs used ...
Can the snapshots use normal files? Because if this is possible we
can have a way to 'save' the LiveCD sessions and mitigate the low
memory systems problem.
> - Changes are stored on a block by block basis. If you write 1 bytes
> the filesystem writes a full block and that gets stored in ram.
>
> - Deleting a file will write a new inode block but won't tell the
> device mapper that blocks are now unused. The ram will still be
> used. Maybe I will patch something into ext2 that will effect freeing
> unused blocks at some point.
Well, that's bad, but not as dangerous as the first problem.
Greetings,
Sergio
--
Sergio Talens-Oliag <sto@debian.org> <http://people.debian.org/~sto/>
Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69
Attachment:
signature.asc
Description: Digital signature