A compressed ext2-filesystem is stored in a file called
on a cdrom.
It is not allowed to mount this filesystem read-write, since it is compressed
(accessed via the cloop-driver that does not allow modifications).
And even if it was not compressed, the filesystem is located in a file on
cdrom for which write-access is impossible anyhow
(if the higher kernel layers "know" that the lower driver
has no "write"-support, as is the case with e.g. an ISO9660 file system,
all write requests will be blocked long
before they reach the driver (and thus cowloop);
more on this in the FAQ).
The following sequence of commands is necessary to mount the compressed
filesystem read-write (the cowloop driver is supposed to be loaded
already with the
# mount /dev/cdrom /mnt/cdrom
# modprobe cloop file=/mnt/cdrom/chicken
# cowdev -a /dev/cloop /tmp/chicken.cow
/dev/cow/0 # the command returns this name now
# mount /dev/cow/0 /cow+chicken
$ cp /etc/termcap /cow+chicken
# umount /dev/cow/0
# cowdev -d /dev/cow/0
# rmmod cloop
# umount /dev/cdrom
After the command
mount has been issued for cowdevice
/dev/cow/0, the situation is as shown in this figure:
Obviously the contents of the compressed ext2-filesystem on cdrom is
unmodified; the modified filesystem-blocks are stored in the
Later on the first four commands can be issued again to continue
with this modified filesystem and make additional changes.
Notice that a filesystem-type is preferred that does not use journaling
(e.g. ext2 instead of ext3) because the additional write-requests for
journaling would unnecessarily populate the cowfile).
Also, mount-options such as
-o noatime are useful for the same reason.
The described sequence can be used to generate Linux LiveCD's
to run Linux stand-alone from a cdrom without modifying the hard disk.
In that case the cowfile could be located in memory by allocating it
on a RAM-disk or on a USB memory-stick.