All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Dickson <SteveD@redhat.com>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
Cc: Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 1/1] umount.nfs: normalize path names during umounts.
Date: Mon, 05 Mar 2012 20:35:01 -0500	[thread overview]
Message-ID: <4F5569C5.1000100@RedHat.com> (raw)
In-Reply-To: <1330995896.5407.8.camel@lade.trondhjem.org>



On 03/05/2012 08:04 PM, Myklebust, Trond wrote:
>>> Is there any reason why we actually care about checking the crap
>>> in /etc/mtab on umount?
>>>
>> Yeah... its called backwards compatibility with older distros...
>> Believe, if I could bury mtab I would... in a New York minute! 
>> I just don't see it happening... 
> 
> Yes, but despite all your work, you are just replacing one broken model
> by another.
>
> 
> At least with the current code, they can _see_ that the model is broken
> and have an immediate incentive to move to the
> mtab-is-a-symlink-to-/proc/mounts based model. The latter is in any case
> the only one that is valid in the mount-namespace based world in which
> we've been living for the past 5 years or so...
> 
I do not disagree with what you are saying... The fact the code/model
is broken is unarguably true... Relying on info in the mtab verses 
/proc/mounts is completely brain dead... But those bits are on the 
street and need to be fixed... So the question is how to fix
them...

Sending out a patch that symbolically links mtab to /proc/mounts
would solve this entire problem! But I just can't make major change
like that in established worlds... Who know what people use mtab
for... I certainly don't. Changing mtab to read-only is recipe for
disaster... IMHO... 

Now if we don't want to take a patch like this in upstream 
that's a different story... This patch is basically meaningless 
when  it comes to new Linux distros... I'm ok with that..
But I do think its wise for us to at least try to be somewhat
backwards compatible....

steved.
 


  reply	other threads:[~2012-03-06  1:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-05 19:36 [PATCH 0/1] Normalized path names on umounts (take 2) Steve Dickson
2012-03-05 19:36 ` [PATCH 1/1] umount.nfs: normalize path names during umounts Steve Dickson
2012-03-05 21:20   ` Malahal Naineni
2012-03-05 21:30     ` Malahal Naineni
2012-03-06  0:28       ` Steve Dickson
2012-03-06  0:27     ` Steve Dickson
2012-03-06  0:31       ` Myklebust, Trond
2012-03-06  0:53         ` Steve Dickson
2012-03-06  1:04           ` Myklebust, Trond
2012-03-06  1:35             ` Steve Dickson [this message]
2012-03-06  1:52               ` Jim Rees
2012-03-06  2:25                 ` Malahal Naineni
2012-03-06  2:38                   ` Steve Dickson
2012-03-05 19:37 ` [PATCH 0/1] Normalized path names on umounts (take 2) Chuck Lever
2012-03-05 19:44   ` 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=4F5569C5.1000100@RedHat.com \
    --to=steved@redhat.com \
    --cc=Trond.Myklebust@netapp.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.