All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Banks <gnb@sgi.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Neil Brown <neilb@suse.de>,
	mehta kiran <kiranmehta1981@yahoo.com>,
	nfs@lists.sourceforge.net, Vijay Chauhan <kernel.vijay@gmail.com>
Subject: Re: 2.4 vs 2.6
Date: Tue, 30 May 2006 11:12:08 +1000	[thread overview]
Message-ID: <20060530011208.GB12818@sgi.com> (raw)
In-Reply-To: <20060529160236.GC6832@fieldses.org>

On Mon, May 29, 2006 at 12:02:36PM -0400, J. Bruce Fields wrote:
> On Mon, May 29, 2006 at 03:55:19PM +1000, Neil Brown wrote:
> > Not exactly necessary, but without it we depend on 'rmtab' to record
> > which clients have the filesystem mounted across a server reboot, and
> > it is not possible to maintain an rmtab file reliably.
> 
> Oh, right.  Hm.  I don't actually understand exactly what the obstacles
> are to maintaining it reliably, though intuitively it's easy to believe
> that it's impossible.  Is the problem just clients that die and never
> come back, or are there inherent race coditions updating the rmtab on
> unmount?

Clients can also ignore network errors when they unmount, or do
some kind of forced unmount which doesn't send an RPC to mountd.
Because clients still work regardless of whether the serverside state
is cleaned up, umount is effectively optional.

So rmtab is not only unreliable but tends to accumulate cruft.  I've
seen reports of rmtab growing to over 500 megabytes (admittedly not
on a Linux box, but the principle is the same).

> > nfsd.export is needed because once auth.unix.ip and nfsd.fh have
> > provided their information - it combines the two together to get
> > export options.
> 
> I don't see why this *has* to be done on demand, though, unless the
> export table is extremely large and only sparsely used.  I might be
> missing something.

/mnt/data *.domain1.company.com(ro,sync) *.domain2.company.com(rw,sync)

Also, ISTR that the combination of the nohide export option and
a client wildcard didn't work properly in 2.4 and the kernel upcall
to mountd in 2.6 fixed that.

Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2006-05-30  1:12 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-25  7:35 2.4 vs 2.6 Vijay Chauhan
2006-05-26  7:29 ` Neil Brown
2006-05-26  7:30   ` Neil Brown
2006-05-26  8:19   ` mehta kiran
2006-05-26 19:31     ` J. Bruce Fields
2006-05-29  5:55       ` Neil Brown
2006-05-29  8:52         ` mehta kiran
2006-05-29 16:02         ` J. Bruce Fields
2006-05-30  1:12           ` Greg Banks [this message]
2006-05-30  1:59             ` J. Bruce Fields
2006-06-13  3:29               ` Neil Brown
2006-06-13 20:42                 ` J. Bruce Fields
2006-06-13 23:22                   ` Neil Brown
2006-06-14  1:29                   ` Greg Banks
2006-06-14  2:15                     ` J. Bruce Fields
2006-06-14  2:22                       ` Greg Banks
2006-06-14  4:18                         ` Neil Brown
2006-06-14  4:36                           ` Greg Banks
2006-06-14 12:48                             ` multiple mountds (was: 2.4 vs 2.6) Greg Banks
2006-06-16  3:52                               ` Neil Brown
2006-06-14 19:40                     ` 2.4 vs 2.6 William A.(Andy) Adamson
2006-06-15  3:17                       ` Greg Banks
     [not found] <fa.iaibikf.1l5injd@ifi.uio.no>
     [not found] ` <fa.m5245vp.h0ukb5@ifi.uio.no>
2003-12-15 10:56   ` Anssi Saari
2003-12-15 17:25     ` David Ford
  -- strict thread matches above, loose matches on Subject: below --
2003-12-01  6:20 XFS for 2.4 Nathan Scott
2003-12-01 14:06 ` Marcelo Tosatti
2003-12-14  1:08   ` 2.4 vs 2.6 Jan Rychter
2003-12-14  1:01     ` Roberto Sanchez
2003-12-14 11:23       ` Måns Rullgård
2003-12-14 18:09         ` Daniel Gryniewicz
2003-12-14  1:53     ` Daniel Gryniewicz
2003-12-14  2:01     ` coderman
2003-12-14 20:23       ` tabris
2003-12-14  7:05     ` Voicu Liviu
2003-12-14 16:01       ` Roberto Sanchez
2003-12-14 17:32         ` Voicu Liviu
2003-12-15  7:23           ` Harry McGregor
2003-12-15  7:51             ` Voicu Liviu
2003-12-14 11:24     ` Frederik Deweerdt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060530011208.GB12818@sgi.com \
    --to=gnb@sgi.com \
    --cc=bfields@fieldses.org \
    --cc=kernel.vijay@gmail.com \
    --cc=kiranmehta1981@yahoo.com \
    --cc=neilb@suse.de \
    --cc=nfs@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.