Slashdot Mirror

Contrary to popular rumors, there are a number of ways to do what you want. I can't vouch for all of these combinations working and wouldn't be too optimistic about tackling some of them. The more advanced stuff can take quite a while to ramp up to speed.

If you don't mind FUSE as an intermediary, there's gitfs that uses git as a file system (which is kind of is anyway, beyond being just a VCS). It creates a new version on every file close. You can point it to a git remote on the same machine or across a network which lives on any filesystem.

You already found that there are some non-mainline kernel modules for filesystems like next3, ext3cow, or tux3 that do versioning on write. NILFS is actually in the kernel these days (since 2.6.something) . More information about NILFS2 shows that it's somewhat slow but that it is in fact a stable, dependable file system.

Subversion has a feature that you can put WebDAV in front of it, mount the WebDAV as a filesystem somewhere, and every write creates a new revision of the file in SVN. That gets you networked and versioned. This works similarly to gitfs but uses WebDAV. You could if you wanted use dav2fs in front of that to treat it like a normal file system again.

You can then share any of these over SMB with Samba. Or you can shared them via NFS.

If you need really high-end, fast, replicated network filesystems you can use any of the clustered storage systems that will use a storage node's underlying files with any of these below that, but that will put your revisions underneath everything else rather than on top. Then there's using something like gitfs with the remote on top of, for example, DRDB, XtreemFS, or Ceph (for example even across CephFS which presents Ceph as a normal POSIX filesystem). This latter option puts your revisions closer to the user and then each revision gets replicated.

I've personally never used some of the more exotic combinations listed here. You could in theory put NILFS2 on LVM with DRBD as the physical layer (since DRBD supports that) and then serve that file system via Samba (CIFS) or NFS which I would expect to work well enough if slowly.

http://blogs.linbit.com/p/406/raspberry-tau-cluster/

DRBD is a great open-source solution to accomplish high-availability and disaster recovery. It's a block level replication device that is compatible with virtually any application.

8.3.0 will be released soon which includes 16TB addressing, 3rd node replication and enhanced sync algorithms.

And of course....it's free :)

http://www.linbit.com/

DRBD is for high-availability clusters with sub-minute failover and synchronous replication. It is not suitable for server-to-desktop file replication, let alone two-way. The DRBD link in the post is horribly outdated; current information about DRBD is available from http://www.linbit.com/. Or from my blog, for that matter. :-)

rsync has some painful deficiencies when it comes to lots of files being synced on a frequent basis. Csync2 (http://oss.linbit.com/csync2) addresses some of those; it may be more useful for the usage scenario described.

Disclosure: I work for LINBIT, the company behind DRBD. Csync2 was written and is being maintained by a former employee of ours.

DRBD is for high-availability clusters with sub-minute failover and synchronous replication. It is not suitable for server-to-desktop file replication, let alone two-way. The DRBD link in the post is horribly outdated; current information about DRBD is available from http://www.linbit.com/. Or from my blog, for that matter. :-)

rsync has some painful deficiencies when it comes to lots of files being synced on a frequent basis. Csync2 (http://oss.linbit.com/csync2) addresses some of those; it may be more useful for the usage scenario described.

Disclosure: I work for LINBIT, the company behind DRBD. Csync2 was written and is being maintained by a former employee of ours.

Here's my own example:

http://lists.linbit.com/pipermail/drbd-user/2005-A ugust/003377.html

What's going on here is that this particular 3ware card doesn't understand 64-bit and so somehow depends on the IOMMU memhole for its memory and if it doesn't have enough, the RAID is lost.

There is Linux HA. This is High Availability Clustering software (via a heartbeat). This along with DRBD ( Disk Replicated Block Device ) you have a very robust cluster.

This uses an Active/Standby setup with a heartbeat between the systems. If the Active is no longer responding, within X seconds (10 by default ) the Standby takes over all the processes that were running on the other system. And ( if needed ) STONITH's (Shot the other node in the head) the other server to ensure that it really IS dead .

We've been running webservers and Oracle database servers here with 0 downtime using heartbeat and drbd.