I (and lots of people where I work) use Dropbox and keep our work source directories in Dropbox. These directories contain close to 20k small files, and we'll typically have many of them hanging around as we work on different code branches.

Dropbox takes a long time to start up, and a long time to sync everything, probably because it has to download and index all those files, and it may not be very efficient to download small files one at a time. I have a theory that I could speed up the start time by:

  1. developing a tool so that code checkouts create a loopback filesystem, and mount that filesystem

  2. allow dropbox to sync only the filesystem blob at the block-level, ignoring the mounted filesystem directory.

Does Dropbox even do block-level sync, and if so, would this improve performance?

  • I know you did not ask for unrelated advice, it was a year ago, and you definitely use some RCS, but I couldn't stop, sorry :) ... So if someone stumbles upon your question, and happens to not know about revision control systems - please do give git or mercurial (hg) or some other source code storage/exchange/versioning system a try instead of relying on a generic solution like Dropbox. – chronos Feb 17 '14 at 21:05
  • 1
    I'm voting to close this question as off-topic because it is about the file synchronization feature of Dropbox, not the web interface. – ale Nov 7 '16 at 16:09

Dropbox does do block-level sync, according to this answer to a ServerFault question.

The blocks in question are 4MB, apparently. Whether your idea of a loopback filesystem / disk image to dump all the 20K files into a single file for Dropbox syncing would speed up Dropbox sync would depend on the speed of your internet connection - you would be trading the local indexing (checking multiple files & protocol delays) for the raw upload bandwidth (even just a few changes would probably require re-uploading the entire disk image).

However, your idea is probably a non-starter for another reason, which is that most filesystems cannot handle external updates to their block storage; you'll get I/O errors and perhaps even kernel panics if Dropbox updates an ext3fs disk image you have loop-mounted. Even if you were to use a shared-disk filesystem that is designed to handle external updates, like GFS2, Dropbox's 4MB block size and delayed update synchronization would probably make this extremely unstable.

Not the answer you're looking for? Browse other questions tagged or ask your own question.