Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

We have a few linux file servers, our sysadmin refuses to do any NFS cross mounting, by cross mounting I mean mounting an nfs share from server A on server B and a share from server B on A .
Anybody knows if there are any problems with this cross mounting?

share|improve this question
1  
This sounds dangerously like "Crossing the streams!" in ghostbusters (: –  gabe. Dec 9 '11 at 15:26
add comment

2 Answers 2

up vote 4 down vote accepted

Ordering the bootup of the two servers can be challenging.

Ideally, you'd like your servers to recover from a power failure without operator intervention. But, of course, some servers need to come up before others—e.g., maybe you need your firewall up before trying to bring up servers that connect externally. Or, you need your NFS servers up before their clients.

One way to do this is to get a smart power strip (e.g., APC managed PDU), and then you can configure power-on delay for each outlet. So you can make sure your firewall and switches turn on first, then your DNS servers, then your NFS servers, etc. Even if you do this manually off a checklist ("turn on A, wait for it to boot, turn on B and C, wait for them to boot, ...") you still want simplicity.

But you can't do that if A depends on B, but B depends on A. In simple cases, its easy enough to work around—A and B just need to start up their own NFS server (and export their local filesystems) before attempting to mount any NFS shares (though this is the opposite of the default ordering). Unless of course you wind up with nested paths, where e.g., a local filesystem is mounted underneath an NFS mount. Or where you add a third server, and then maybe shares from A are mounted under ones from B on C.

Working around that kind of stuff manually isn't too hard, of course, but you don't want to be doing that after a power failure. You've probably got unplanned problems to solve (e.g., stuff that broke from unexpected power loss, or dependencies you didn't know about), while everyone is complaining about it being down, so its best not to set up known, avoidable problems that'll eat your time.

Also, mounting and then re-exporting an NFS share is probably ill-advised, if for no other reason than the network overhead of sending all the data twice. Not like the client can't just mount both servers.

edit: One more reason—when an NFS server goes down, any processes on a client trying to access that server go into disk ("uninterruptible") sleep. That may lead to "contagion" from one NFS server failing to the other failing (from essential processes going into disk sleep, or running out of resources from cron jobs spawning and not finishing, etc.). (This shows a D in ps, if you're wondering)

share|improve this answer
    
since these cross mounts are not necessary for boot up, what about a corn job that periodically checks to see if mounts are properly mounted and if not remounts them. Instead of mounting them at boot up? –  Ali Dec 9 '11 at 4:19
1  
@Ali: That cron job can go very wrong (e.g., "is it mounted?" hangs, cron keeps spawning more and more checks), so if I were going to do it, I'd just write startup scripts that I'd order properly—and then use background mounts. But its more complexity, which your sysadmin may want to avoid—especially if there isn't a good reason to add it. –  derobert Dec 9 '11 at 16:29
add comment

It is not a problem to cross-mount filesystems like that as long as there is nothing on those filesystems (like necessary OS libs) that either machine needs.

You could for example have each NFS server export its file systems, and then have both of them mount all the filesystems using the automounter.

Or, mount the filesystems in fstab, but use mount options that will let the mount wait until the NFS server is available. I believe this is the bg option.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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