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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list