Fix MNAMELEN or reimplement struct statfs

[Bryan Drewery]

On Tue, Nov 19 21:53:38 UTC 2013 Jilles Tjoelker wrote:
> On Mon, Nov 18, 2013 at 11:01:42AM -0800, Doug Ambrisko wrote:
>> On Sat, Nov 16, 2013 at 08:31:29PM +0200, Konstantin Belousov wrote:
>> | I think that struct mount should have a const char * field where the
>> | non-trimmed path is stored and used for match at unmount. f_mntonname
>> | truncation would be only unfortunate user interface glitch.
> 
>> Note that we are not storing the path in mount structure so no structures
>> have changed which is nice since then we haven't introduced any real
>> ABI breakage.  So we could MFC this.  The match isn't critical since
>> umount will fall back to fsid and work.  One thing that might be good to
>> do is change umount to try to umount via fsid first and then do the
>> match if the fsid failed versus the other way round that it does now.
> 
>> The problem I see is if someone tries to do things based on the parsed
>> output of mount/df then that will fail since the output is truncated.
> 
> As noted in comments in sbin/umount/umount.c, the statfs() call is
> deliberately after the mount list checks because it may block forever
> for unresponsive NFS servers. It would be unfortunate if hung NFS
> filesystems would have to be forcibly unmounted by copy/pasting the fsid
> from 'mount -v'.

From a user perspective, I'd love to see this get committed and MFC'd.
It's very odd to have ENAMETOOLONG errors while traversing .zfs/snapshot.

However, this would make the situation worse for poudriere, which is
what this particular thread was started on. It does exactly what you
worry about, it parses mount(1) output and umounts all descendants for a
given path. We do the same thing at my work for our base build system,
and I believe FreeNAS is doing something like this. So it's not uncommon.

Or did the situation improve with the latest patch to show the full
mount path in mount(1)?

We could implement umount -r, but I'm not convinced that is adequate due
to unknown use of mount(1) output. We really need the real path exported
to userland somehow, and preferably to mount(1) by default to not break
scripts.

This may not be a clean solution, but couldn't we add another syscall,
say getfsmntpath(2), and have mount(1) use both statfs(2) and
getfsmntpath(2) to show a proper output?

-- 
Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20140411/9d1214d9/attachment.sig>