A standard facility in modern Linux kernels is the so called "device mapper".
This paragraph briefly compares its pros and cons with respect to cowloop.
Manual page 'dmsetup(8)' describes its basic use, but a comparison with
cowloop requires the so-called 'snapshot' target type, which is
as of yet not documented on that page.
The file 'Documentation/dm/snapshot.txt' has slightly more information.
This is how to do it (the italic parts are fixed,
the roman parts are choices to be filled in by yourself):
# dmsetup create cowdevname 0 size snapshot \
lowerdevice cowfiledevice p chunksize
cowdevname is the name you choose for the newly
to-be-created block device, comparable to our cow-blockdevice
(in our examples the
/dev name will be created automatically,
and it provides you with a linear range of blocks, starting
with block number
size blocks large.
lowerdevice is the block device to be shielded from
write accesses, comparable to our 'rdofile'.
cowfiledevice is the place where written block data
will be diverted to, comparable to our 'cowfile'.
The device mapper requires both to be actual block device names,
where cowloop has the possibility to use regular files for either one.
p parameter is for 'persistent':
the content of the cowfiledevice will survive a reboot.
The alternative for this parameter is
which will keep more information in memory:
less overhead, but the information is gone after a reboot.
chunksize parameter determines the size
(in 512-byte units) of the copied-on-write chunks.
The documentation uses
64 as a sample value.
Apart from the fact that this 'device mapper' is a standard 2.6 kernel
facility in most mainstream distributions, the big advantage is that
device mapper is significantly more efficient than cowloop is.
The reason for this, but also the price you pay for this, is that
device mapper requires the
cowfiledevice (where the
diverted writes are stored) to be a block device instead of a regular file.
Obviously, it is much easier to reroute a block driver request from one
driver to another one, than it is to convert a block driver read/write request
into a file read/write operation.
But block devices are very coarse resources in a Linux system,
whereas (large amounts of) regular files are cheap and easy.
In our opinion, this point alone justifies the existence of cowloop
besides the device mapper facility.
Cowloop allows the cowfile to be merged back directly into the original rdofile,
with the help of the cowmerge-command.
The device mapper requires an intermediate copy of the entire block device
to be made when this facility is required.
For the sake of completeness: the problem with write calls being blocked
by higher kernel layers, if the file system concerned does not have
a write routine on board (as described in our FAQ)
still exists with the device mapper as it does with cowloop.