Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 2006-10-27 14:45:40 -0500 \ Dave Dykstra: > On Sat, Oct 14, 2006 at 12:09:15PM -0600, Dan Brown wrote: > > On Saturday, October 14, 2006 Mustafa A. Hashmi wrote: > > > On 10/10/06, Dan Brown <danb at zu.com> wrote: > ... > > > > One thing I keep seeing in various > > > > documents however is a warning not to have the server mount its own > > > > NFS shares. There is never reason (even a vague reason) given why not > > > > to however. I can see the obvious reasons (eg. infinitely nested > > > > filesystems via symlinks/mounts, crossmounts, etc), but my directory structures should > > > > not need anything like this at all. Other than overall system complexity, > > > > I don't see any reasons to not be able to self mount NFS with a whole > > > > lot of trouble. > > > > > > Odd -- the NFS-HA howto shows how to do exactly this. Also: > > > we've deployed this for mail and web without issues this far, > > > albeit, in a non-complex environment. > > > > You mean the one at http://linux-ha.org/HaNFS ? It examples a setup with to > > HA NFS servers, and two clients (although not specifiying whether they are > > one in the same) . This, along with a fair number of other articles I've > > read on using DRBD and NFS all have something like this (from the > > linux-ha.org page): > > > > "NFS-mounting any filesystem on your NFS servers is highly discouraged." > > > > But none of them ever really give a good explanation(if at all) why. > > Having not done much with NFS before, and certainly not in a production > > environment, I don't have the experience with NFS to understand many reasons > > behind this sort of statement. > > The biggest problem was with the fuser command hanging. I have updated > that web page to link to the mailing list threads where the problems > were detailed. I think the basic problem is the possibility of distributed resource starvation deadlock. say, you mount "yourself" via nfs, the vm decides to flush out some things, these have to be shipped via drbd replication, which may cause some memory allocations on the receiving side, which in turn could (indirectly, not directly, we do use the correct flags most of the time) trigger the vm there to flush something too, ... bad things may happen if you have io-load and memory pressure and some network-load too, and io causing additional network load. -- : Lars Ellenberg Tel +43-1-8178292-0 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Schoenbrunner Str. 244, A-1120 Vienna/Europe http://www.linbit.com : __ please use the "List-Reply" function of your email client.