Date: Sat, 16 May 2015 09:59:19 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= <trasz@FreeBSD.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: nmount(2) vs 64 bit flags [Was: Re: RFC: should automounted file systems be exportable?] Message-ID: <20150516075919.GB4528@brick.home> In-Reply-To: <599930852.36285001.1431431429794.JavaMail.root@uoguelph.ca> References: <20150512074602.GA93864@brick.home> <599930852.36285001.1431431429794.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On 0512T0750, Rick Macklem wrote: > Edward Napierala wrote: > > On 0511T2217, Rick Macklem wrote: > > > A recent bug was reported related to mountd and the > > > "automounted" flag. > > > > > > Loosely related to this is the question... > > > Should automounted file systems be exportable? > > > > > > I haven't tested it, but I suspect that it would be > > > broken and the NFS server will reply NFSERR_STALE > > > after the file system has been dismounted. > > > > > > So, should I patch mountd so that it won't export > > > automounted file systems? > > > > Exporting an automounted filesystem doesn't seem to make much sense, > > I agree, but I'm not sure if adding code to prevent it is such > > a good idea. If the user asks for it, by putting it into exports(5), > > it's his fault; the only thing this code could add would be a more > > friendly error message. > > > > > Well, my thinking is that the recent patch to mountd that avoids > doing mount update for non-exported file systems + one that doesn't > allow automounted volumes to be exported fixes this bug: > http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel > > That way, there is no rush w.r.t. how to update the high order > bits of flags. (As noted in the comment w.r.t. the review of D2506, > I'm not sure if an updated syscall is allowed to be MFC'd.) > Since MNT_AUTOMOUNTED is the only high order bit at this time, > once it is fixed, no MFC of the more generic fix is needed. > > Make sense? rick Yes. To sum this up: one approach of dealing with it would be to add a separate textual "flags" field (https://reviews.freebsd.org/D2506); another is extending the flags nmount(2) argument to uint64 (https://reviews.freebsd.org/D2524), and autors of both don't intend to bring either of them into the tree at this time, since the mountd problem was actually fixed earlier, by a simple mountd(8) change. To be honest, I wonder if we should just have an API to convert binary flags (as obtained from statfs) back to textual form (iov), and use that to ignore the 'flags' argument altogether and pass everything in textual form. Either way - let's leave it until it's actually needed.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150516075919.GB4528>