atconsultancy logo
cowloop logo
atcomputing logo

spacerHome

spacerNews

spacerDownload

spacerFAQ

 

SourceForge.net Logo

Tux

Cowloop versus device mapper

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
The cowdevname is the name you choose for the newly to-be-created block device, comparable to our cow-blockdevice (in our examples the /dev/cow/0 etc.). Its /dev name will be created automatically, and it provides you with a linear range of blocks, starting with block number 0 and size blocks large.

The lowerdevice is the block device to be shielded from write accesses, comparable to our 'rdofile'. The 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.

The p parameter is for 'persistent': the content of the cowfiledevice will survive a reboot. The alternative for this parameter is n, which will keep more information in memory: less overhead, but the information is gone after a reboot.

Finally, the 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.

spacerIntroduction

spacerOverview

spacerInstall

spacerLoad & unload

spacerCowfiles

spacerCommands

spacerStatus info

spacerExample 1

spacerExample 2

spacerExample 3

small @ logoCowloop vs.
   device mapper

spacerView as single page


© AT Consultancy bv, Nijmegen, The Netherlands  -  www.ATConsultancy.nl
© AT Computing bv, Nijmegen, The Netherlands  -  www.ATComputing.nl - www.ATComputing.net