foo@xxxxxxxxx wrote:
foo@xxxxxxxxx wrote:
I have a need to create a CoW (copy on write) on the root filesystem
using
device mapper. I do this manually after installation. I'd like to see
this type of setup integrated into anaconda.
Although I have a specific need, I see many other possible applications
for CoWs that could use this type of feature.
o Embedded flash devices with persistence that are easy to clear or
reset.
o Stateless installations where the CoW(s) are cleared at reboot or
logout.
o Testing installations where you may have several CoWs for for testing
a
single base installation that are easy to cleared or reset.
o Virtual installations that using the same root filesystem with
modifications by the different instances saved in different CoWs
I would like to see this handled in the anaconda partition setup where
you
could define a partition as a CoW for one of the mounted filesystems.
Add
a kernel parameter similar to the “root=” except something like “cow=”
to
define a root filesystem CoW and have a similar file as “fstab” except
maybe “cowtab” that defines non-root filesystem CoWs and where they are
located.
I think you may even have more ideas. I think even the LiveCDs that use
device mapper with an in-memory CoW due to the read-only CD media would
benefit from anaconda support (add a kernel parameter something like
“cow=RAM=100mb”.
Am I crazy or alone in my needs?
See all the overlay/persistence threads on fedora-livecd-list. I have
some very alpha code here-
http://filteredperception.org/downloads/overlay/
https://www.redhat.com/archives/fedora-livecd-list/2007-July/msg00158.html
In general what you are saying makes sense. I also know that Jon
Nettleton has been discussing very similar things on a thread in
fedora-devel called "a fused based initfs".
In general what you are saying sounds good to me. There definitely
seems to be some room for convergence of all these aspects of cow usage.
Thanks for you comments.
I looked at your code. I think it looks good, however, I was looking for
a more general anaconda option.
I know, I wasn't suggesting that my code solved your problems, just that
it was in the same problem space, and might be interesting to compare
and contrast. Or perhaps find some way to more logically support both
sets of scenarios using the same mechanisms.
I may be wrong, but the heavy use of loopbacks seems problematic as it
leads to filesystem dependencies.
I don't understand. The method I was using, was just the livecd case,
and in this instance, the RW loop-file must live on some other
filesystem (vfat usbstick being the canonical example). I'm not sure
what you mean by filesystem dependencies. I am currently seeing a
problem with the filesystem cache probably being responsible for poor
behaviour in a yank-the-plug-and-have-to-fsck-on-next-boot kind of
scenario. I hope to find some set of options and/or tricks that makes
that not be an issue.
However, it may be needed in your case.
Can't you just use another partition on a r/w media for your CoW?
Absolutely, and it is a much simpler solution. And probably more robust
for the reasons mentioned above. asdas@xxxxxxxxxx posted a very simple
implementation of that on fedora-livecd-list recently. I think for the
short term, it might be the better option. But if I can get it so that
you can use a file in your ipod's filesystem, rather than a partition on
your ipod, I think the user-benefits are clearly pretty big.
Do you
think anaconda should get involved with loopback mounts?
100% Absolutely. I think anaconda should resurrect support for
installing to loopback files on an ntfs filesystem, now that that is
possible in fedora.
Having a linux newbie be able to install to a file on their winblowz
ntfs, rather than go through all the partitioning crap, is a HUGE win IMHO.
I'm looking for an anaconda option that is a little different from the
classic ext[23] or lvm partition setups by extending ext[23] setup to
include CoWs, as these seem to be fundamentally different than lvm.
However, the proposed “/etc/cowtab” could be parsed for loopback mounts,
although dependency logic would have to be observed somehow.
I'm still a bit weary about /etc/cowtab. Kind of hard to manage except
when you boot without any overlay/cow layers.
The thing my implementation is doing, is autosearching (mounting
read-only) all partitions at boot, and looking for cow devices. If
finding more than one, it prompts the user. (see my kernel cmdline
semantics, i.e. overlay[=[devspec:][pathspec]].
I guess cowtab would accomplish the same sort of thing, but instead of
searching all devices, it would use short-name aliases that you set up
beforehand in the cowtab.
Obviously in the livecd case, there is no 'master' writable storage
device, thus no logical place to put a centralized managed cowtab.
Although, my
brain swells when thinking about loopback mounts of the root filestem :)
It opens a lot of wonderful possibilities doesn't it? Installation to a
file on ntfs and no partitioning crap. Having dozens of temporary or
special purpose COW layers...
-dmc
