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 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.