[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: umount Dead NFS Directory



> > Hello there,
> >
> >       I got a problem while trying to umount NFS. I have two web servers,
> >     one exports its /var/www for NFS share and the other mounts it as its
> > own DocumentRoot too, thus I got two web servers with exactly the same
> > contents. If the one as NFS server malfunctions, the other NFS client
> > should umount its /var/www and link it to the other place.
> 
> link it to what other place?

    I rsync the NFS mounted /var/www to a local directory often on my NFS
    client host. This can be my redundant DocumentRoot should NFS fail.

> 
> >       I wonder what makes this happen, and I think that controlling the
> >     interface directly to meet my need is a bad idea. Any comment or
> > advice is appreciated.
> 
> have you tried killing apache and anything else using  /var/www
> (you can use lsof or another similar tool to find out what is using it)
> before unmounting?

    Yes. I use lsof to grep the PID and kick them away always before
    trying to umount /var/www. But this does not always work. If the
    disaster (NFS not responding) happens, lsof will fail because it 
    tried to access my unavailable /var/www. By the way, I never try 
    to stop my apache server.

> 
> AFS may be a better approach, though I haven't used it much. Or some
> other form of distributed filesystem.
> 
> on my webservers if I need 2 with identical content I just use rsync.
> 

    Yes. rsync is a good way. However, since my /var/www is over 20000
    files, with a total size around 400 MB and many developers dive into
    it, I need a mechanism to keep these two /var/www EXACTLY identical
    from either incoming or outgoing access. Hence NFS is my choice.

> depending on the kind of activity you do over NFS(e.g. read only or
> writing or lots of writing of small files etc), it may be advantageous
> to use another sytem to host the NFS, I have found that my redhat 7.3
> has a much more solid NFS implimentation then my debian 3.0 machines.
> Solaris's is pretty strong too. It may be my kernel(2.2.19) vs
> redhat's 2.4.18, but the bulk of the problems I have encountered
> with debian's NFS is the rpc.statd service(which appears to be
> completely userland based)
> 
> nate
> 

    I appreciate these useful experience!

--------------------- Original Message Ends --------------------





Reply to: