You need the kernel sources for at least 2.6.32. Some elder versions may work, but we have not tested it. Currently, MARS Light builds only with 64bit kernels. Go to your linux source tree, and apply one of the pre-patches for MARS. You can find them in the subdirectory pre-patches/ of the MARS sources. These pre-patches are almost trivial, they contain only a few EXPORT_SYMBOL() statements. Porting to other kernel versions should be trivial. One of the pre-patches has been ported to an openvz kernel even by one of our sysadmins, who usually does no C programming. So this should be no major hurdle. Because of the need for some small pre-patches, we recommend to build MARS inside the kernel source tree (in-tree). If you are an experience sysadmin and want to build MARS as an external kernel module, you may try the Debian based scripts provided by our sysadmins. Be warned that you have to check yourself for source compatibility, the right compiler flags, etc; very nasty errors may appear if you fail to do so! Therefore, try the in-tree method first. For the in-tree build, you need to also apply one of the patches pre-patches/vanilla-*/*necessary-for-in-tree-build.patch or similar. Go to ${your_kernel_source}/block/ and clone the MARS git repository there. Then build your kernel as usual. You need to use 64bit. In addition, you need to enable the following options before MARS shows up at all: PROC_SYSCTL HIGH_RES_TIMERS Don't enable CONFIG_DEBUG_SG (this will currently not work until it is fixed). In Kconfig, you will find lots of additional options for MARS. Most of them should be left at their default. It suffices just to switch on MARS as a whole, and let it build as a single kernel module. If no Kconfig options for MARS show up in the in-tree build, you have probably forgotten to apply the appropriate pre-patches/vanilla-*/*necessary-for-in-tree-build.patch or similar. Finally, copy userspace/marsadm to some appropriate location in your $PATH. Do the following at both your primary and secondary node: After booting your pre-patched kernel, don't modprobe mars. Before that, create an empty filesystem with at least 100GB (ext4 is highly recommended; there seem to remain some recursion deadlock problems with xfs which will be hopefully fixed in the next time) and mount it to /mars/ . Additionally, you need an empty block device having exactly the same size at both nodes. In the following, they are called /dev/vg-x/myspace . On the primary: marsadm create-cluster On the secondary: marsadm join-cluster ${hostname_of_primary} Only after that, do on both nodes: modprobe mars On the primary: marsadm create-resource myspace /dev/vg-x/myspace Wait a few seconds until the state information about the new resource has spread over the whole cluster. On the secondary: marsadm join-resource myspace /dev/vg-x/myspace Shortly after that, the initial full sync should start automatically. On the primary, a device /dev/mars/myspace should appear, having exactly the same size as /dev/vg-x/myspace . Now you can use /dev/mars/myspace on the primary for creating a filesystem, mounting, or exporting via iSCSI, etc. From time to time, you should execute the following commands on one of your nodes: marsadm log-rotate all sleep 10 marsadm log-delete-all all ... in order to prevent your /mars/ filesystem from running full. hint: use cron jobs for automation. Most marsadm commands are very similar to drbdadm. Details can be found in docu/mars-manual.pdf. The sourcecode of marsadm is a very simple and stupid perl script, which intentionally does not use any perl module and no OO. The source code will tell you almost anything about the symlinks present in /mars/. If you are curious about how MARS replicates its state information over the network, just do the following on both nodes: watch ls -l /mars/resource-myspace/ Alternatively / additionally, you may try Joerg's script mars-status.pl which will deliver colorful state reports from the practical viewpoint of an experienced sysadmin.