Jeff Layton <jlayton@xxxxxxxxxxxxxxx> wrote: > I think one of the neat things here is that we can now error out as > soon as a bogus mount option is passed in. It means that the 'sloppy' option can also now be implemented in userspace. > > Once fsmount() has been called, further write() calls will incur EBUSY, > > even if the fsmount() fails. read() is still possible to retrieve error > > information. > > > > What's the rationale for the above behavior? > > A failed attempt to graft it into the tree doesn't seem like it would > have any real effect on the mount_context. While I can't think of a use > case for being able to try fsmount() again, I don't quite understand > why we'd prohibit someone from doing it. The mount procedure is allowed to preallocate resources and attach them to the mount context and ->mount() is allowed to use them up, say by transferring them to the superblock. The mount context is then in a degraded state and cannot necessarily be reused. David -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
