[Fedora-livecd-list] I urgently need your help in Fedora LiveCD.

[Douglas McClendon]

Thiago Braga Santana wrote:
> Hi, Fedora-live-list.
> 
> 
> Sorry to ask directly to you, but I asked some questions
> to the Fedora Project group, with no succesfull answer.
> 
> http://www.fedora.org.br/fortopic7100.html 
> <http://www.fedora.org.br/fortopic7100.html>
> 
> My name is Thiago Santana and I doing a derivative of
> Fedora LiveCD for a Point of Sale application.
> 
> I need to understand a little bit of the Ramdrive
> conceptual framework used by you in 'Fedora 7 LiveCD'.
> 
> There is a file system mounted on the root directory
> ("/"). How the system is it able to distinguish the
> files and
> programs previously recorded on the CD image from files
> and programs created by me?

The mechanism used is a device mapper snapshot, where the base of the 
snapshot is an ext3 filesystem image located inside a squashfs 
filesystem image, located inside the cdrom filesystem.

The overlay part of the snapshot is a loop device, associated with a 
sparse file created in tmpfs.

The general idea is that the root filesystem is the devicemapper device, 
so whenever a write goes to it, the write actually goes to the sparse 
file in tmpfs.  Unlike the other popular method of 'copy on write' for 
livecds, i.e. using unionfs, this means that changes stored to ram 
happen on a block by block basis, not on a file by file basis.

> If I understand correctly, some files are stored in RAM,
> but I didn't get how the file system manages the
> available storage space. I want to know how to calculate
> the RAM space I need for my files.

Currently that is a bit complicated.  I have submitted patches and 
outlined a solution for this on the list historically.  The current 
problem is that the tmpfs the overlay file is stored on, is not(?) 
visible at runtime, because it is the initramfs tmpfs.  The solution I 
outlined involved creating a tmpfs for it, and making it available to 
'df' at runtime.

Alternately, if your ram currently exceeds 1G(?), then the amount of 
space you have is limited to 512M, because that is the current size 
chosen for the sparse file.  In this case, you could watch how much you 
have available with 'dmsetup status'.

But the real solution IMO is to make the sparse file ridiculously large, 
and expose the tmpfs it is mounted on, so that monitoring and control 
happens in that fashion.

If you review the persistence patches I posted to this list, you'll see 
how to implement this (e.g. 'df /mnt/overlayfs')

> 
> Furthermore, it appears to be that when I open some file
> from the image for editing, the full contents of the
> file is copied to RAM. Is that the case? If it is so,
> what happens if I open a great number of files?

Just opening a file should not cause a hit.  But the instant that the 
file gets modified by any program (editor, ...) the changes to the 
filesystem are going to eat your ram.

Unlike the unionfs method used by ubuntu, a downside of the devicemapper 
snapshot method is that if you create a file and delete it, the ram is 
not freed.

Anybody want to volunteer to put this info on a wikipage for future 
reference?

-dmc


> 
> I will be waiting for your response.
> 
> Thank advance your information.
> 
> My best regards,
> 
> Thiago Santana
> 
> 
> ------------------------------------------------------------------------
> 
> --
> Fedora-livecd-list mailing list
> Fedora-livecd-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-livecd-list