we have a small company with employee’s located at differing locations. We all need to access the DroboFS, but the office has a terrible upload speed. I would like to mirror the contents of the drobo-fs to a remote webserver, but with a 2 way sync.

I was looking to use rsync to sync in one direction, then use another rsync command to sync in the other direction, however i don’t know how to do this over FTP. i also looked at using unison however i cant figure out how to install this on the drobo.

Any suggestions?


I would think a VPN would be a better choice for something like this. Even using something as simple as SyncToy 2.1 form MS to do the 2 way sync. If only that cloud app for the Drobo FS was out.

cloud smoud… the reason we use these is so we don’t need to pay for high bandwidth and storage spaces.

we need drobo to support some basic functionality, ssh, scp, ftp, rsync, man, etc… hell my iphone have these installed why not the expensive black plastic box i bought?

I have successfully cross-compiled unison version 2.32.52, and am successfully using it to two-way sync a DroboFS with a linux server. If there is some place I can upload it for others to make use of, I would be happy to.

Could you post the sequence of steps you took to compile it? I would then confirm it and post them to droboports.com.

Below is the sequence of steps I took.

I got most of the information on setting up the cross-compile environment from these sites:


I got some very useful information on the ocaml and unison compiles from these sites:


Here is what I did (I did this on a Debian Squeeze amd64 install, but the actual work occurred in a schroot environment running Debian Lenny i386):

be careful of linewraps below - I’m not sure how the forum board will format this

download the Drobo FS toolchain from http://www.codesourcery.com/gnu_toolchains/arm/releases/2007q1-21

wget -O ‘arm-2007q1-21-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2’ ‘http://www.codesourcery.com/sgpp/lite/arm/releases/download?pkg_prefix=arm&target=arm-none-linux-gnueabi:2007q1-21&host=i686-pc-linux-gnu

sudo -i

apt-get install schroot debootstrap
cat << END_OF_DROBOFS > /etc/schroot/chroot.d/drobofs
description=Lenny for DroboApps on Drobo FS

mkdir -p /var/chroot/drobofs
debootstrap --variant=buildd --arch i386 lenny /var/chroot/drobofs http://ftp.debian.org/debian

cd /var/chroot/drobofs/usr/local
tar xjf /arm-2007q1-21-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
echo ‘export PATH="/usr/local/arm-2007q1/bin:$PATH"’ >> /var/chroot/drobofs/root/.profile

schroot -c drobofs -d /root
apt-get update
apt-get install vim wget automake autoconf libtool autotools-dev m4 less

build ocaml for the host architecture:

wget ‘http://caml.inria.fr/pub/distrib/ocaml-3.12/ocaml-3.12.0.tar.gz
zcat ocaml-3.12.0.tar.gz | tar xf -
cp -a ocaml-3.12.0 ocaml-3.12.0.host
cd ocaml-3.12.0.host
./configure -host i386-unknown-linux-gnu
make world
make opt
cd …

build ocaml cross-compiler:

wget ‘http://web.yl.is.s.u-tokyo.ac.jp/~tosh/cross-ocaml/diffs/cross-ocaml-3.12.0-001.diff.gz
cd ocaml-3.12.0
zcat …/cross-ocaml-3.12.0-001.diff.gz | patch -p1

Note: exit values in script below were determined by cross-compiling the

original source files and running them on the DroboFS

cat << END_OF_CROSS_COMPILE > config/auto-aux/cross_compile_conf.arm-none-linux-gnueabi
case “$1” in
exit 0;;
echo “4 4 4 2”;;
exit 0;;
exit 1;;
exit 0;;
exit 0;;
exit 0;;
exit 100;;

./configure -prefix /usr/local/ocaml-arm -host arm-none-linux-gnueabi -cc /usr/local/arm-2007q1/bin/arm-none-linux-gnueabi-gcc -as /usr/local/arm-2007q1/bin/arm-none-linux-gnueabi-as -aspp “/usr/local/arm-2007q1/bin/arm-none-linux-gnueabi-gcc -E” -partialld “/usr/local/arm-2007q1/bin/arm-none-linux-gnueabi-ld -r”
make world

ignore error

mv byterun/ocamlrun byterun/ocamlrun.target
cp …/ocaml-3.12.0.host/byterun/ocamlrun byterun/ocamlrun
make world

ignore error

mv yacc/ocamlyacc yacc/ocamlyacc.target
cp …/ocaml-3.12.0.host/yacc/ocamlyacc yacc/ocamlyacc
make world

ignore error

mv otherlibs/unix/dllunix.so otherlibs/unix/dllunix.so.target
cp …/ocaml-3.12.0.host/otherlibs/unix/dllunix.so otherlibs/unix/dllunix.so
make world

ignore error

mv otherlibs/str/dllcamlstr.so otherlibs/str/dllcamlstr.so.target
cp …/ocaml-3.12.0.host/otherlibs/str/dllcamlstr.so otherlibs/str/dllcamlstr.so
make world
make opt
make install
cd …

build unison:

Debian unison version 2.32.52-2 has been patched to compile with ocaml-3.12

wget ‘http://ftp.de.debian.org/debian/pool/main/u/unison/unison_2.32.52.orig.tar.gz
wget ‘http://ftp.de.debian.org/debian/pool/main/u/unison/unison_2.32.52-2.debian.tar.gz
wget ‘http://ftp.de.debian.org/debian/pool/main/u/unison/unison_2.32.52-2.dsc
dpkg-source -x unison_2.32.52-2.dsc
cd unison-2.32.52
export PATH="/usr/local/ocaml-arm/bin:$PATH"
make UISTYLE=text NATIVE=false

ignore etags error

unison binary is in cwd

Thanks for the write up. I’ll try to reproduce the steps and post in on DroboPorts.com.

Quick update: I just finished posting the tutorials online for both OCaml and unison.

I have adapted the instructions to match the environment presented on DroboPorts (for instance, the VM setup is a bit different), but otherwise it worked just as you described. I took the liberty to mirror some of the files in there as well (your config file and the patch), to make sure that they do not suddenly become unavailable.

Thanks again for the info!

No problem, and thanks for including it on your site!

I’ve just started using the version of Unison from Drobo Ports site, but performance of syncing is extremely slow e.g. approx 12 hours to sync 1gb.

What are others experience?


What is the CPU usage? Is Unison taking all the CPU from the Drobo?

It doesn’t look like Unison is taking all the CPU less than 1%, but memory is at 180% and load average with little else happening on the box is around 1.7 and disk light is constantly on…

Average load 1.7? Is this value from uptime? Because if it is, then this means that your Drobo is under a very heavy load. It may not be unison causing the load, though, it could be some other background process.

Hi Ricardo,

The load average was from top, and I couldn’t see any other processes using any significant amount of cpu.

I’ve just kicked off another sync, and here is some more info:

Prior to starting sync, top indicated load average of 0.00, no other processes were hitting the box significantly.

Initial stage of sync whilst looking for changes, top indicates unison using 20-30% cpu, 50% memory and increasing, and a load average of about 1.50. 285mb of changes are identified. Load average reduces back down to 0.00 whilst waiting for responses to sync options.

During synchronisation of changes, unison cpu% varies between 0-50%, load average is 1.70-2.20, and elapsed time to complete the synchronisation of 285mb is approx 40 minutes…