Date: Fri, 11 Apr 2014 20:21:46 -0500 From: Bryan Drewery <bdrewery@FreeBSD.org> To: ambrisko@ambrisko.com Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, kib@FreeBSD.org Subject: Re: Fix MNAMELEN or reimplement struct statfs Message-ID: <5348952A.3080304@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --epfBOrRsj5c7RDfRGUfIATCN4kdNdsl8R Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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_mntonnam= e >> | truncation would be only unfortunate user interface glitch. >=20 >> Note that we are not storing the path in mount structure so no structu= res >> 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. >=20 >> 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. >=20 > 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 fsi= d > from 'mount -v'. =46rom 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? --=20 Regards, Bryan Drewery --epfBOrRsj5c7RDfRGUfIATCN4kdNdsl8R Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTSJUxAAoJEDXXcbtuRpfPoHgH/jvncwRHDY9Qlh63Dpt01Yn7 GVcGUb26I2++oLWeFcHMCwzF5suuT9xPG0vdX4OQOJ2VdTBHLc9ZjnpiJ4RlvcgV 5hEGhsvnYvaH8THVVaMqrpjUJN6l1dWf+p04Dz510k5ICMp5h79WB9qXzZbfCl3n 7c9kjHSU0Gb9Fq8s9i0kXl6IQVej+jWOG75N4Z8d5ZR0ln4DY2FD5WovSbK1xnmb xkGnc4njovngQkoSivnLzQfBpgUuLZKQvAF/wlT/MK1Fw8uCt5j91AEVEJenb8uC mpQr1Om06yrPn9jAaKMjbnlFEtvFKoihrYVDbymrUzv/04JKxRh+aT7L5Pm76X0= =Tftw -----END PGP SIGNATURE----- --epfBOrRsj5c7RDfRGUfIATCN4kdNdsl8R--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5348952A.3080304>