Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm trying to find an optimum solution for accessing the NFS file share in my company. We have a central file server in North America and has 30GB~50GB of updated data everyday. And it's very slow for our Europe and Asia branches to access directly.

Therefore, I'm trying to setup two replicate servers in those continents. I'm currently using rsync, but wonder if there exists a better solution acts more like a distributed RAID, which allows the user to transparently access the file whether synced or not. And user request will be dispatched to remote server if the file is not yet synced.

I'm now looking into DRBD, but it seems not to have the functionality of auto-dispatching requests. Does anyone know if there's a better solution?


migration rejected from Jan 21 at 19:10

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by HopelessN00b Jan 21 at 19:10

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

3 Answers 3

NFSv4 allows you to do exactly what you need, more exactly, the pNFS extensions in 4.1. However, when you roll out this in production, take great care, because it's quite new.

If you're not bound to NFS, then there are many distributed, parallell filesystems available (however, you may want to narrow down your search to POSIX-compatible ones).


Do all locations need to be able to write files to their local fileserver, or does only one location do updates? If the former, you're going to need some crazy thing like Coda (or perhaps newer versions of AFS could do the trick). If only one location's writing, you could possibly get away with DRBD but it's not the right tool for the job.

I'd be more inclined to look at a way to partition the dataset so that each site had their own fileset locally, which they worked on the most, and just live with the performance hit when they needed to access the occasional file from another site. Of course, that only works if there's some sort of locality of access; if it's a complete free-for-all, you're in for a very, very painful time.


I think this depends on how much parallelism you want to support. If you don't expect file collisions (where two offices write to the same file in short order) a solution like lsyncd might be exactly what you are looking for:

On the other hand if you need more locking and have a solid pipe between offices, I would check out gluster. Its simple to setup and will allow for a single live namespace without issue.