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.
next prev parent 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).