linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve Dickson <SteveD@redhat.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH 6/6] nfs(5): Document remount behavior
Date: Thu, 28 Oct 2010 15:55:47 -0400	[thread overview]
Message-ID: <4CC9D543.4020004@RedHat.com> (raw)
In-Reply-To: <BFCEEA71-05CB-4D4F-9ED8-64B140E20D2C@oracle.com>



On 10/28/2010 02:58 PM, Chuck Lever wrote:
> 
> On Oct 28, 2010, at 2:02 PM, Steve Dickson wrote:
> 
>> Chuck,
>>
>> I'm a bit concern about this patch.... 
>>
>> I'm asking myself who is going care how remounts update 
>> /etc/mtab and what mode is used.
> 
> Someone who has done a remount and found that it doesn't behave as they expect. 
> I've handled bug reports like this.  When customers want to see existing 
> documentation of strange behavior, it's pretty important to have something to
> point them to.  Documentation is the first thing I'm asked for by customers 
> and system engineers who encounter weird NFS behavior.
Documentation is great! I too get numerous requests for documentation.
That's why I think are the first 3 paragraphs in "THE REMOUNT OPTION"
is perfect! Well written and to the point... Its the rest of 
the section I don't think we needed... that's all... 
 
> 
>> I just thinking that type of info 
>> adds a lot verbiage that nobody really care about.
> 
> Don't you think that's a bit harsh and even disrespectful? 
By no means... whatsoever... I was just being honest...
maybe a bit too brutally... ;-) My apologies if it came 
off in that manner...  

> What criteria do you use to decide that "no-one cares"?
I can't image anybody caring about how the inners of /etc/mtab
are being maintained on an NFS umount... As long as the unmount
works, that's all they care about... 
> 
> This patch documents very confusing behavior that is not documented anywhere else.
> It's not documented elsewhere because other file systems don't have a dependency 
> on /etc/mtab as we have.  This also documents why replacing /etc/mtab with 
> /proc/mounts will cause some fuzzy NFS umount behavior (which is exactly the documentation you were looking for last week).
> 
> The fact that it took me so long to figure out is evidence enough that this is 
> not obvious and needs to be written down somewhere.  Where else should we document
> behavior that is related to /etc/fstab and mount(8), and is NFS specific?
How about the NFS FAQ? 

All I'm saying is that type of details information (how mtab is managed) is
not useful to a system admin trying figure out how to use remount 
on an NFS file system... So I think its a waste to put in the man page... 

> 
>> Plus why are
>> we documenting something (/etc/mtab) that will be going 
>> away as soon as humanly possible? 
> 
> Do you have a schedule for this?  I've talked very recently with Karel, 
> and libmount is not even ready to be published.  The work to integrate 
> libmount into every mount subcommand sounds like it could be a ways in 
> the future.  (Karel and I even discussed me doing this work for mount.nfs).
No I don't... but it can come soon enough... IMHO... 
Cool... Karel is a good guy to work with... 

> 
> I expect we will have a dependence on /etc/mtab for a while yet.  And, 
> it's pretty easy to change these docs once we've transitioned.
> 
>> Basically I'm saying the entire "Unmounting after a remount" 
>> section is not needed. Only the 3 paragraphs in "THE REMOUNT OPTION"
>> section are needed IMHO... 
> 
> 
> I'll consider recrafting it, but this is important and confusing 
> behavior that must be documented.  We can argue about how the information 
> is presented, but just throwing it all out and ignoring it is not an option.
> 
Good...

All I'm saying make the it concise and to the point so its useful
to a system admin... Like the first 3 paragraphs are... 

And maybe I'm wrong...  but... I just don't think an system admin 
really cares what happens to the mtab after a umount of a 
remounted mount point... As long as the unmount works... they are
happy... again... IMHO... 

steved.

  reply	other threads:[~2010-10-28 19:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-26 15:57 [PATCH 0/6] More fix-ups for nfs-utils-1.2.4 Chuck Lever
2010-10-26 15:57 ` [PATCH 1/6] nfs-utils: Remove all uses of AI_ADDRCONFIG Chuck Lever
2010-10-26 15:58 ` [PATCH 2/6] mount: Fix compiler warning in nfs_parse_retry_option() Chuck Lever
2010-10-26 15:58 ` [PATCH 3/6] mount.nfs: Fix memory leak in nfs_sys_mount() Chuck Lever
2010-10-26 15:58 ` [PATCH 4/6] mount.nfs: mnt_freq and mnt_pass are always zero Chuck Lever
2010-10-26 15:58 ` [PATCH 5/6] nfs(5): Grammar and style fixes Chuck Lever
2010-10-26 15:58 ` [PATCH 6/6] nfs(5): Document remount behavior Chuck Lever
2010-10-28 18:02   ` Steve Dickson
2010-10-28 18:58     ` Chuck Lever
2010-10-28 19:55       ` Steve Dickson [this message]
     [not found] ` <20101026155216.19184.36979.stgit-RytpoXr2tKZ9HhUboXbp9zCvJB+x5qRC@public.gmane.org>
2010-10-28 15:32   ` [PATCH 0/6] More fix-ups for nfs-utils-1.2.4 Steve Dickson
     [not found]     ` <4CC997A8.6060803-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2010-10-28 15:39       ` Chuck Lever
2010-11-01 12:13   ` Steve Dickson

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=4CC9D543.4020004@RedHat.com \
    --to=steved@redhat.com \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).