From: Karel Zak <kzak@redhat.com>
To: Eric Rannaud <eric.rannaud@gmail.com>
Cc: util-linux@vger.kernel.org, Dave Reisner <d@falconindy.com>
Subject: Re: Using findmnt in the presence of a stale NFS mount
Date: Tue, 17 Jun 2014 14:37:54 +0200 [thread overview]
Message-ID: <20140617123754.GM30975@x2.net.home> (raw)
In-Reply-To: <CA+zRj8VZSxJ8dPYOY_wSS5zbxaue1Vy-gyCkYxfLVqA_3FjQfA@mail.gmail.com>
On Mon, Jun 16, 2014 at 09:02:14AM -0700, Eric Rannaud wrote:
> Another solution would be to change canonicalize_path(): before
> calling realpath(fs->target), it would first check if fs->target is
> otherwise listed in mtab (using the comparison
> strcmp(from_mtab_fs->target, fs->target), not recursively using
> mnt_fs_target_match()). If found in mtab, canonicalize_path() knows
> that fs->target is not a symlink and it does not need to call
> realpath(fs->target), and it won't blow up.
>
> There is no need for a command line option: canonicalize_path() can do
> this all the time, it will not change its semantics. However, findmnt
I like the idea that we can rely on /proc/self/mountinfo and assume
that all the mountpoints are already canonicalized so we can skip the
extra canonicalize_path().
But it would be probably better to extend struct libmnt_cache than
change too low-level canonicalize_path().
We can add two functions:
mnt_cache_set_targets(struct libmnt_cache *cache, struct libmnt_table *mtab);
mnt_resolve_target(char *path, struct libmnt_cache *cache);
and check for @path in @mtab before canonicalize_path().
Then we can use mnt_resolve_target() in mnt_fs_match_target() and
mnt_table_find_target().
And in findmnt.c all you need is to parse /proc/self/mountinfo and call
mnt_cache_set_targets() for the global cache when --target is specified
(or always?).
> would have to systematically read /proc/mounts or mtab in an
> additional secondary structure, even if --fstab is specified. That
> requires changing findmnt's logic quite a bit, however, as currently
> it doesn't read mtab if --fstab is specified.
We have to be very careful with /proc/mounts (and mountinfo), unfortunately
it has horrible performance impact for kernel on huge servers to generate
the /proc files.
> If you wish, I can have a crack at writing such a patch.
Go ahead.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
prev parent reply other threads:[~2014-06-17 12:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-10 15:03 Using findmnt in the presence of a stale NFS mount Eric Rannaud
2014-06-16 13:28 ` Karel Zak
2014-06-16 14:00 ` Karel Zak
2014-06-16 16:02 ` Eric Rannaud
2014-06-17 12:37 ` Karel Zak [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=20140617123754.GM30975@x2.net.home \
--to=kzak@redhat.com \
--cc=d@falconindy.com \
--cc=eric.rannaud@gmail.com \
--cc=util-linux@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