All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Dickson <SteveD@redhat.com>
To: chuck.lever@oracle.com
Cc: nfs@lists.sourceforge.net
Subject: Re: [PATCH 02/23] mount.nfs: fix printf's normally hidden	behind NFS_MOUNT_DEBUG
Date: Mon, 30 Jul 2007 13:32:29 -0400	[thread overview]
Message-ID: <46AE20AD.4010107@RedHat.com> (raw)
In-Reply-To: <46ADFC9C.8050503@oracle.com>

Chuck Lever wrote:
> Steve Dickson wrote:
>> Chuck Lever wrote:
>>> After I enabled NFS_MOUNT_DEBUG the compiler started spitting out 
>>> warnings.
>>> Fix up commas, output formatting, and double-wide character support.
>> Aren't these debugging statements basically useless because one has to
>> recompile to turn them on... Wouldn't it make more sense to add
>> '-o mntdebug' flag so these could be turned on at will?
> 
> Useless for folks who don't want to or can't compile nfs-utils 
> themselves, yes.  But I think the usefulness of these is for anyone who 
> is developing mount.  They aren't for debugging problems mounting 
> shares, but for debugging changes to mount itself.
> 
> I'm not opposed to making these debugging messages available dynamically 
> (if we really believe they will be useful for everyday system 
> administrators).... but....
> 
> Miklos has illuminated an important distinction between mount options 
> that affect the behavior of the mounted file system, and mount options 
> that control who can mount and how the mount takes place.  NFS is one of 
> the worst offenders in mixing the two.
> 
> A "mntdebug" option would be of the latter type, and I'm beginning to 
> think twice about the value of adding more of these.  I'm thinking about 
> a way of specifying those types of options in some other way; for 
> example, by using a separate NFS mount policy file like nsswitch.conf to 
> set these up.  Just a random thought.
> 
> Or, rather, instead of "-o mntdebug" we might consider --mntdebug 
> instead; that is, use a command line option instead of a mount option.
> 
> It's a nit, I know.
Right... a command line option to the actual mount binary is probably
the way to go... The binary could pass a MS_DEBUG flag to the mount.nfs
binary which would enable the debugging...

steved.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

      reply	other threads:[~2007-07-30 17:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-28 21:49 [PATCH 02/23] mount.nfs: fix printf's normally hidden behind NFS_MOUNT_DEBUG Chuck Lever
2007-07-30 11:49 ` Steve Dickson
2007-07-30 14:58   ` Chuck Lever
2007-07-30 17:32     ` Steve Dickson [this message]

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=46AE20AD.4010107@RedHat.com \
    --to=steved@redhat.com \
    --cc=chuck.lever@oracle.com \
    --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.