Re: request for patches: showing mount options
> > The removal of /etc/mtab in favor of /proc/mounts is a new requirement, > > and is not as trivial as you might hope. Internally the NFS client > > represents the mount options as a binary data structure, and it contains > > only the information that has traditionally been passed into the kernel > > by the current mount command. The user-space-only options are not > > passed to the kernel nor stored in the data structure. > > > > Adding facilities to store information about every possible mount > > option, including the user-space-only ones, will take a bit of time, but > > is possible, if not straightforward. We just have to understand all the > > dependencies. > > I still have doubts. The removal of /etc/mtab is nice, but a little > unreal wish. Do we really want to store non-kernel data (options) in > kernel? What about options that are not closely related to any > filesystem -- for example "loop="? "loop=DEV" is special, we've already talked about that. For example if we have an mtab entry like this: /dir/foo.iso /mnt/image ext3 rw,loop=/dev/loop/0 0 0 It says: /dev/loop/0 has been automatically set up by mount(8) from /dir/foo.iso and so needs to be torn down by umount(8). It is not a property of the mount, rather the property of the device. So what we really want is a file to store this, and only this info: /var/lib/mount/loop: /dev/loop/0 /dir/foo.iso /dev/loop/2 /dir/bar.img ... Notice, there's nothing about the _mountpoint_ in this file. > Maybe we can replace /etc/mtab with something more useful > (e.g. /var/run/mount/.tab) for really user-space-only information. The problem with storing mount options in userspace is that unprivileged mounts/umounts won't work in the presense of those, we cannot _force_ an unprivileged user to update a file. So we want to avoid storing options in userspace as long as possible. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
> On Tue, 2007-07-31 at 17:16 -0400, Chuck Lever wrote: > > Miklos Szeredi wrote: > > > It would be nice to have all this stuff in 2.6.24, which doesn't leave > > > a lot of time. > > > > Yes, that would be nice, but there's a lot of stuff that needs to get > > done before this. NFS IPv6, for example, is a higher priority than > > refactoring to remove /etc/mtab -- the US government has a new > > requirement in 2008 for IPv6 support in any software that it purchases, > > and NFS may be a stumbling block for distributors if it doesn't have it. > > > > So I'd say "no way" for 2.6.24, but it's really Trond's call to make. > > I never like to tell people what their priorities should be. If someone > is interested enough to do the work, then it will get done, however this > cannot make the top of my already-overloaded list of priorities for > 2.6.24, and it would appear that Chuck is busy too. > > Any other volunteers out there? I'm willing to help out. I could have basically fixed up all filesystems, but I think it's better if the maintainers do it and are aware that this needs to be looked at each time a new option is added. But there's no problem with making exceptions if the maintainers are busy. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
On Tue, 2007-07-31 at 17:16 -0400, Chuck Lever wrote: Miklos Szeredi wrote: It would be nice to have all this stuff in 2.6.24, which doesn't leave a lot of time. Yes, that would be nice, but there's a lot of stuff that needs to get done before this. NFS IPv6, for example, is a higher priority than refactoring to remove /etc/mtab -- the US government has a new requirement in 2008 for IPv6 support in any software that it purchases, and NFS may be a stumbling block for distributors if it doesn't have it. So I'd say no way for 2.6.24, but it's really Trond's call to make. I never like to tell people what their priorities should be. If someone is interested enough to do the work, then it will get done, however this cannot make the top of my already-overloaded list of priorities for 2.6.24, and it would appear that Chuck is busy too. Any other volunteers out there? I'm willing to help out. I could have basically fixed up all filesystems, but I think it's better if the maintainers do it and are aware that this needs to be looked at each time a new option is added. But there's no problem with making exceptions if the maintainers are busy. Miklos - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
The removal of /etc/mtab in favor of /proc/mounts is a new requirement, and is not as trivial as you might hope. Internally the NFS client represents the mount options as a binary data structure, and it contains only the information that has traditionally been passed into the kernel by the current mount command. The user-space-only options are not passed to the kernel nor stored in the data structure. Adding facilities to store information about every possible mount option, including the user-space-only ones, will take a bit of time, but is possible, if not straightforward. We just have to understand all the dependencies. I still have doubts. The removal of /etc/mtab is nice, but a little unreal wish. Do we really want to store non-kernel data (options) in kernel? What about options that are not closely related to any filesystem -- for example loop=? loop=DEV is special, we've already talked about that. For example if we have an mtab entry like this: /dir/foo.iso /mnt/image ext3 rw,loop=/dev/loop/0 0 0 It says: /dev/loop/0 has been automatically set up by mount(8) from /dir/foo.iso and so needs to be torn down by umount(8). It is not a property of the mount, rather the property of the device. So what we really want is a file to store this, and only this info: /var/lib/mount/loop: /dev/loop/0 /dir/foo.iso /dev/loop/2 /dir/bar.img ... Notice, there's nothing about the _mountpoint_ in this file. Maybe we can replace /etc/mtab with something more useful (e.g. /var/run/mount/mntid.tab) for really user-space-only information. The problem with storing mount options in userspace is that unprivileged mounts/umounts won't work in the presense of those, we cannot _force_ an unprivileged user to update a file. So we want to avoid storing options in userspace as long as possible. Miklos - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
On Tue, Jul 31, 2007 at 10:19:57AM -0400, Chuck Lever wrote: > The removal of /etc/mtab in favor of /proc/mounts is a new requirement, > and is not as trivial as you might hope. Internally the NFS client > represents the mount options as a binary data structure, and it contains > only the information that has traditionally been passed into the kernel > by the current mount command. The user-space-only options are not > passed to the kernel nor stored in the data structure. > > Adding facilities to store information about every possible mount > option, including the user-space-only ones, will take a bit of time, but > is possible, if not straightforward. We just have to understand all the > dependencies. I still have doubts. The removal of /etc/mtab is nice, but a little unreal wish. Do we really want to store non-kernel data (options) in kernel? What about options that are not closely related to any filesystem -- for example "loop="? Maybe we can replace /etc/mtab with something more useful (e.g. /var/run/mount/.tab) for really user-space-only information. It doesn't mean that Miklos's audit of all filesystems and request for patches is bad thing. The /proc/mounts has to provide complete information at least about kernel mount options. Karel -- Karel Zak <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
On Tue, 2007-07-31 at 17:16 -0400, Chuck Lever wrote: > Miklos Szeredi wrote: > > It would be nice to have all this stuff in 2.6.24, which doesn't leave > > a lot of time. > > Yes, that would be nice, but there's a lot of stuff that needs to get > done before this. NFS IPv6, for example, is a higher priority than > refactoring to remove /etc/mtab -- the US government has a new > requirement in 2008 for IPv6 support in any software that it purchases, > and NFS may be a stumbling block for distributors if it doesn't have it. > > So I'd say "no way" for 2.6.24, but it's really Trond's call to make. I never like to tell people what their priorities should be. If someone is interested enough to do the work, then it will get done, however this cannot make the top of my already-overloaded list of priorities for 2.6.24, and it would appear that Chuck is busy too. Any other volunteers out there? Cheers Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
Miklos Szeredi wrote: After a successful mount, the NFS mount command tucks some options into /etc/mtab that reflect which mountd was used for the mount, and what protocol version and port was used for the mount request. Those options are not passed to the kernel, and do not appear in /proc/mounts today. See nfs(5)'s discussion of the mountport, mounthost, mountprog, and mountvers options. However, the trend for NFS is to push mount option parsing into the kernel. Thus all options will be passed to the kernel, and at that point it should be able to reflect the mount* options in /proc/mounts. But it doesn't do that quite yet. Trond, do you have a roadmap for this? Well I'm actually doing the coding, and Trond is playing more of an architectural role. OK, what your estimage for this then? I don't have an estimate. This is all very slippery because once I get into a part of the code, we discover a lot of issues that we didn't expect. The NFS mount stuff is largely historical; we've all forgotten (or never really knew) how it works. It would be nice to have all this stuff in 2.6.24, which doesn't leave a lot of time. Yes, that would be nice, but there's a lot of stuff that needs to get done before this. NFS IPv6, for example, is a higher priority than refactoring to remove /etc/mtab -- the US government has a new requirement in 2008 for IPv6 support in any software that it purchases, and NFS may be a stumbling block for distributors if it doesn't have it. So I'd say "no way" for 2.6.24, but it's really Trond's call to make. But if it's just those four options you mentioned, it should be managable. I do not think there needs to be some generic code to hande userspace-only options, it would be perfectly fine just to parse, store and show them like all the other options. Like you, I don't expect it will be difficult to implement, but I have too many balls in the air to make any promises at the moment. Plus, we can't really predict when distributors will feel the in-kernel mount parsing stuff will be ready for their users. begin:vcard fn:Chuck Lever n:Lever;Chuck org:Oracle Corporation;Corporate Architecture: Linux Projects Group adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA title:Principal Member of Staff tel;work:+1 248 614 5091 x-mozilla-html:FALSE url:http://oss.oracle.com/~cel version:2.1 end:vcard
Re: request for patches: showing mount options
> >> After a successful mount, the NFS mount command tucks some options into > >> /etc/mtab that reflect which mountd was used for the mount, and what > >> protocol version and port was used for the mount request. Those options > >> are not passed to the kernel, and do not appear in /proc/mounts today. > >> See nfs(5)'s discussion of the mountport, mounthost, mountprog, and > >> mountvers options. > >> > >> However, the trend for NFS is to push mount option parsing into the > >> kernel. Thus all options will be passed to the kernel, and at that > >> point it should be able to reflect the mount* options in /proc/mounts. > >> But it doesn't do that quite yet. > > > > Trond, do you have a roadmap for this? > > Well I'm actually doing the coding, and Trond is playing more of an > architectural role. OK, what your estimage for this then? It would be nice to have all this stuff in 2.6.24, which doesn't leave a lot of time. But if it's just those four options you mentioned, it should be managable. I do not think there needs to be some generic code to hande userspace-only options, it would be perfectly fine just to parse, store and show them like all the other options. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
Miklos Szeredi wrote: After a successful mount, the NFS mount command tucks some options into /etc/mtab that reflect which mountd was used for the mount, and what protocol version and port was used for the mount request. Those options are not passed to the kernel, and do not appear in /proc/mounts today. See nfs(5)'s discussion of the mountport, mounthost, mountprog, and mountvers options. However, the trend for NFS is to push mount option parsing into the kernel. Thus all options will be passed to the kernel, and at that point it should be able to reflect the mount* options in /proc/mounts. But it doesn't do that quite yet. Trond, do you have a roadmap for this? Well I'm actually doing the coding, and Trond is playing more of an architectural role. We have a first implementation of in-kernel mount option parsing in 2.6.23-rc now. I'm currently working on the user-space piece of this. (And actually, now is a great time to review the new kernel part, while it is still quite young.) However, the NFS mount user-space pieces have undergone radical change recently. The mount.nfs helper was split from the mount command just last year, and is only now starting to go into distributions. This is very old code that has been hacked on for over a decade, so it is taking a little while to rediscover its history and modernize it before we move forward. I expect that both the kernel part and the user-space part will evolve together over the next few months as we clarify the full set of requirements. The requirements for this effort now include: + making new mount options simple to implement; + removing ABI dependencies between mount.nfs and the kernel NFS client; + an eventual merge of the nfs and nfs4 file system types; + improved error handling and reporting during the mount process; + support for NFS over IPv6. I think there is also some talk about fully supporting SELinux as well, but I haven't been following that closely. The removal of /etc/mtab in favor of /proc/mounts is a new requirement, and is not as trivial as you might hope. Internally the NFS client represents the mount options as a binary data structure, and it contains only the information that has traditionally been passed into the kernel by the current mount command. The user-space-only options are not passed to the kernel nor stored in the data structure. Adding facilities to store information about every possible mount option, including the user-space-only ones, will take a bit of time, but is possible, if not straightforward. We just have to understand all the dependencies. begin:vcard fn:Chuck Lever n:Lever;Chuck org:Oracle Corporation;Corporate Architecture: Linux Projects Group adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA title:Principal Member of Staff tel;work:+1 248 614 5091 x-mozilla-html:FALSE url:http://oss.oracle.com/~cel version:2.1 end:vcard
Re: request for patches: showing mount options
> After a successful mount, the NFS mount command tucks some options into > /etc/mtab that reflect which mountd was used for the mount, and what > protocol version and port was used for the mount request. Those options > are not passed to the kernel, and do not appear in /proc/mounts today. > See nfs(5)'s discussion of the mountport, mounthost, mountprog, and > mountvers options. > > However, the trend for NFS is to push mount option parsing into the > kernel. Thus all options will be passed to the kernel, and at that > point it should be able to reflect the mount* options in /proc/mounts. > But it doesn't do that quite yet. Trond, do you have a roadmap for this? > I'm wondering if there are other such cases in other file systems. Anything that has /sbin/mount.XXX could be doing this. According to Karel, those are nfs, cifs and ocfs2. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
After a successful mount, the NFS mount command tucks some options into /etc/mtab that reflect which mountd was used for the mount, and what protocol version and port was used for the mount request. Those options are not passed to the kernel, and do not appear in /proc/mounts today. See nfs(5)'s discussion of the mountport, mounthost, mountprog, and mountvers options. However, the trend for NFS is to push mount option parsing into the kernel. Thus all options will be passed to the kernel, and at that point it should be able to reflect the mount* options in /proc/mounts. But it doesn't do that quite yet. Trond, do you have a roadmap for this? I'm wondering if there are other such cases in other file systems. Anything that has /sbin/mount.XXX could be doing this. According to Karel, those are nfs, cifs and ocfs2. Miklos - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
Miklos Szeredi wrote: After a successful mount, the NFS mount command tucks some options into /etc/mtab that reflect which mountd was used for the mount, and what protocol version and port was used for the mount request. Those options are not passed to the kernel, and do not appear in /proc/mounts today. See nfs(5)'s discussion of the mountport, mounthost, mountprog, and mountvers options. However, the trend for NFS is to push mount option parsing into the kernel. Thus all options will be passed to the kernel, and at that point it should be able to reflect the mount* options in /proc/mounts. But it doesn't do that quite yet. Trond, do you have a roadmap for this? Well I'm actually doing the coding, and Trond is playing more of an architectural role. We have a first implementation of in-kernel mount option parsing in 2.6.23-rc now. I'm currently working on the user-space piece of this. (And actually, now is a great time to review the new kernel part, while it is still quite young.) However, the NFS mount user-space pieces have undergone radical change recently. The mount.nfs helper was split from the mount command just last year, and is only now starting to go into distributions. This is very old code that has been hacked on for over a decade, so it is taking a little while to rediscover its history and modernize it before we move forward. I expect that both the kernel part and the user-space part will evolve together over the next few months as we clarify the full set of requirements. The requirements for this effort now include: + making new mount options simple to implement; + removing ABI dependencies between mount.nfs and the kernel NFS client; + an eventual merge of the nfs and nfs4 file system types; + improved error handling and reporting during the mount process; + support for NFS over IPv6. I think there is also some talk about fully supporting SELinux as well, but I haven't been following that closely. The removal of /etc/mtab in favor of /proc/mounts is a new requirement, and is not as trivial as you might hope. Internally the NFS client represents the mount options as a binary data structure, and it contains only the information that has traditionally been passed into the kernel by the current mount command. The user-space-only options are not passed to the kernel nor stored in the data structure. Adding facilities to store information about every possible mount option, including the user-space-only ones, will take a bit of time, but is possible, if not straightforward. We just have to understand all the dependencies. begin:vcard fn:Chuck Lever n:Lever;Chuck org:Oracle Corporation;Corporate Architecture: Linux Projects Group adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA title:Principal Member of Staff tel;work:+1 248 614 5091 x-mozilla-html:FALSE url:http://oss.oracle.com/~cel version:2.1 end:vcard
Re: request for patches: showing mount options
After a successful mount, the NFS mount command tucks some options into /etc/mtab that reflect which mountd was used for the mount, and what protocol version and port was used for the mount request. Those options are not passed to the kernel, and do not appear in /proc/mounts today. See nfs(5)'s discussion of the mountport, mounthost, mountprog, and mountvers options. However, the trend for NFS is to push mount option parsing into the kernel. Thus all options will be passed to the kernel, and at that point it should be able to reflect the mount* options in /proc/mounts. But it doesn't do that quite yet. Trond, do you have a roadmap for this? Well I'm actually doing the coding, and Trond is playing more of an architectural role. OK, what your estimage for this then? It would be nice to have all this stuff in 2.6.24, which doesn't leave a lot of time. But if it's just those four options you mentioned, it should be managable. I do not think there needs to be some generic code to hande userspace-only options, it would be perfectly fine just to parse, store and show them like all the other options. Miklos - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
Miklos Szeredi wrote: After a successful mount, the NFS mount command tucks some options into /etc/mtab that reflect which mountd was used for the mount, and what protocol version and port was used for the mount request. Those options are not passed to the kernel, and do not appear in /proc/mounts today. See nfs(5)'s discussion of the mountport, mounthost, mountprog, and mountvers options. However, the trend for NFS is to push mount option parsing into the kernel. Thus all options will be passed to the kernel, and at that point it should be able to reflect the mount* options in /proc/mounts. But it doesn't do that quite yet. Trond, do you have a roadmap for this? Well I'm actually doing the coding, and Trond is playing more of an architectural role. OK, what your estimage for this then? I don't have an estimate. This is all very slippery because once I get into a part of the code, we discover a lot of issues that we didn't expect. The NFS mount stuff is largely historical; we've all forgotten (or never really knew) how it works. It would be nice to have all this stuff in 2.6.24, which doesn't leave a lot of time. Yes, that would be nice, but there's a lot of stuff that needs to get done before this. NFS IPv6, for example, is a higher priority than refactoring to remove /etc/mtab -- the US government has a new requirement in 2008 for IPv6 support in any software that it purchases, and NFS may be a stumbling block for distributors if it doesn't have it. So I'd say no way for 2.6.24, but it's really Trond's call to make. But if it's just those four options you mentioned, it should be managable. I do not think there needs to be some generic code to hande userspace-only options, it would be perfectly fine just to parse, store and show them like all the other options. Like you, I don't expect it will be difficult to implement, but I have too many balls in the air to make any promises at the moment. Plus, we can't really predict when distributors will feel the in-kernel mount parsing stuff will be ready for their users. begin:vcard fn:Chuck Lever n:Lever;Chuck org:Oracle Corporation;Corporate Architecture: Linux Projects Group adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA title:Principal Member of Staff tel;work:+1 248 614 5091 x-mozilla-html:FALSE url:http://oss.oracle.com/~cel version:2.1 end:vcard
Re: request for patches: showing mount options
On Tue, 2007-07-31 at 17:16 -0400, Chuck Lever wrote: Miklos Szeredi wrote: It would be nice to have all this stuff in 2.6.24, which doesn't leave a lot of time. Yes, that would be nice, but there's a lot of stuff that needs to get done before this. NFS IPv6, for example, is a higher priority than refactoring to remove /etc/mtab -- the US government has a new requirement in 2008 for IPv6 support in any software that it purchases, and NFS may be a stumbling block for distributors if it doesn't have it. So I'd say no way for 2.6.24, but it's really Trond's call to make. I never like to tell people what their priorities should be. If someone is interested enough to do the work, then it will get done, however this cannot make the top of my already-overloaded list of priorities for 2.6.24, and it would appear that Chuck is busy too. Any other volunteers out there? Cheers Trond - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
On Tue, Jul 31, 2007 at 10:19:57AM -0400, Chuck Lever wrote: The removal of /etc/mtab in favor of /proc/mounts is a new requirement, and is not as trivial as you might hope. Internally the NFS client represents the mount options as a binary data structure, and it contains only the information that has traditionally been passed into the kernel by the current mount command. The user-space-only options are not passed to the kernel nor stored in the data structure. Adding facilities to store information about every possible mount option, including the user-space-only ones, will take a bit of time, but is possible, if not straightforward. We just have to understand all the dependencies. I still have doubts. The removal of /etc/mtab is nice, but a little unreal wish. Do we really want to store non-kernel data (options) in kernel? What about options that are not closely related to any filesystem -- for example loop=? Maybe we can replace /etc/mtab with something more useful (e.g. /var/run/mount/mntid.tab) for really user-space-only information. It doesn't mean that Miklos's audit of all filesystems and request for patches is bad thing. The /proc/mounts has to provide complete information at least about kernel mount options. Karel -- Karel Zak [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
Miklos Szeredi wrote: Some mount options are never passed to the kernel, and thus can't appear in /proc/mounts. Examples include user, users, and _netdev for NFS. These options control *who* may mount and *when* to mount. They are not a property of the mount itself and are not added to /etc/mtab. There's a "user=ID" option that is added to /etc/mtab in case of user mounts. This identifies the owner of the mount, so that it can be unmounted by that user. There are patches in -mm that enable the kernel to store this info. Do you have other examples in mind? There are a few more cases for NFS mount. After a successful mount, the NFS mount command tucks some options into /etc/mtab that reflect which mountd was used for the mount, and what protocol version and port was used for the mount request. Those options are not passed to the kernel, and do not appear in /proc/mounts today. See nfs(5)'s discussion of the mountport, mounthost, mountprog, and mountvers options. However, the trend for NFS is to push mount option parsing into the kernel. Thus all options will be passed to the kernel, and at that point it should be able to reflect the mount* options in /proc/mounts. But it doesn't do that quite yet. I'm wondering if there are other such cases in other file systems. begin:vcard fn:Chuck Lever n:Lever;Chuck org:Oracle Corporation;Corporate Architecture: Linux Projects Group adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA title:Principal Member of Staff tel;work:+1 248 614 5091 x-mozilla-html:FALSE url:http://oss.oracle.com/~cel version:2.1 end:vcard
Re: request for patches: showing mount options
Miklos Szeredi wrote: Some mount options are never passed to the kernel, and thus can't appear in /proc/mounts. Examples include user, users, and _netdev for NFS. These options control *who* may mount and *when* to mount. They are not a property of the mount itself and are not added to /etc/mtab. There's a user=ID option that is added to /etc/mtab in case of user mounts. This identifies the owner of the mount, so that it can be unmounted by that user. There are patches in -mm that enable the kernel to store this info. Do you have other examples in mind? There are a few more cases for NFS mount. After a successful mount, the NFS mount command tucks some options into /etc/mtab that reflect which mountd was used for the mount, and what protocol version and port was used for the mount request. Those options are not passed to the kernel, and do not appear in /proc/mounts today. See nfs(5)'s discussion of the mountport, mounthost, mountprog, and mountvers options. However, the trend for NFS is to push mount option parsing into the kernel. Thus all options will be passed to the kernel, and at that point it should be able to reflect the mount* options in /proc/mounts. But it doesn't do that quite yet. I'm wondering if there are other such cases in other file systems. begin:vcard fn:Chuck Lever n:Lever;Chuck org:Oracle Corporation;Corporate Architecture: Linux Projects Group adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA title:Principal Member of Staff tel;work:+1 248 614 5091 x-mozilla-html:FALSE url:http://oss.oracle.com/~cel version:2.1 end:vcard
Re: request for patches: showing mount options
[cc trim on purpose, just autofs interest here] On Jul 28 2007 14:45, Ian Kent wrote: > >Oh .. sorry, I wasn't paying enough attention. > >But now might be a good time to propose the removal of autofs and rename >autofs4 to autofs. I would need to provide some way to map autofs4 >module load requests to autofs for backward compatibility but haven't >thought about that yet. You could use EXPORT_SYMBOL in autofs.ko that autofs4.ko uses. Or write an autofs4.c that does try_module_get(autofs) on _init. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
[cc trim on purpose, just autofs interest here] On Jul 28 2007 14:45, Ian Kent wrote: Oh .. sorry, I wasn't paying enough attention. But now might be a good time to propose the removal of autofs and rename autofs4 to autofs. I would need to provide some way to map autofs4 module load requests to autofs for backward compatibility but haven't thought about that yet. You could use EXPORT_SYMBOL in autofs.ko that autofs4.ko uses. Or write an autofs4.c that does try_module_get(autofs) on _init. Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
On Fri, 2007-07-27 at 17:40 +0200, Miklos Szeredi wrote: > > all - fs has options, but doesn't define ->show_options() > > some - fs defines ->show_options(), but some options are not shown > > noopt - fs does not have options > > good - fs shows all options > > patch - I have a patch > > [...] > > > > autofs all > > > > I'm not sure I understand this. > > How does autofs show it's options without a ->show_options method? > > It doesn't. The "all" means, all of them need to be added to > ->show_options(), not that all are shown. Oh .. sorry, I wasn't paying enough attention. But now might be a good time to propose the removal of autofs and rename autofs4 to autofs. I would need to provide some way to map autofs4 module load requests to autofs for backward compatibility but haven't thought about that yet. > > I can see now that this is slightly confusing, sorry. > > So the ones that need attention are "all" and "some". The others are > fine in theory. Of course I may have missed something. > > > > autofs4 some > > > > OK, uid and gid aren't shown. > > That should be straight forward to fix. > > What's your time frame for this? > > ASAP ;) > > 2.6.24 would be a nice, but it won't be easy... The autofs4 (and, if needed autofs) should be straight forward. I'll do these. Ian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
On Fri, 2007-07-27 at 17:40 +0200, Miklos Szeredi wrote: all - fs has options, but doesn't define -show_options() some - fs defines -show_options(), but some options are not shown noopt - fs does not have options good - fs shows all options patch - I have a patch [...] autofs all I'm not sure I understand this. How does autofs show it's options without a -show_options method? It doesn't. The all means, all of them need to be added to -show_options(), not that all are shown. Oh .. sorry, I wasn't paying enough attention. But now might be a good time to propose the removal of autofs and rename autofs4 to autofs. I would need to provide some way to map autofs4 module load requests to autofs for backward compatibility but haven't thought about that yet. I can see now that this is slightly confusing, sorry. So the ones that need attention are all and some. The others are fine in theory. Of course I may have missed something. autofs4 some OK, uid and gid aren't shown. That should be straight forward to fix. What's your time frame for this? ASAP ;) 2.6.24 would be a nice, but it won't be easy... The autofs4 (and, if needed autofs) should be straight forward. I'll do these. Ian - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
> >> Some mount options are never passed to the kernel, and thus can't appear > >> in /proc/mounts. Examples include user, users, and _netdev for NFS. > > > > These options control *who* may mount and *when* to mount. They are > > not a property of the mount itself and are not added to /etc/mtab. > > > > There's a "user=ID" option that is added to /etc/mtab in case of user > > mounts. This identifies the owner of the mount, so that it can be > > unmounted by that user. There are patches in -mm that enable the > > kernel to store this info. > > > > Do you have other examples in mind? > > [no]quota comes to mind; These are passed to the kernel. > also auto, This controls when a filesystem is mounted, same category as '_netdev' > [no]owner, [no]group, These control who can mount the filesystem, same category as 'user' and 'users' > quiet/loud, I can't find these in the manual as universal options. Quiet is defined for a couple of filesystems but with different meaning for each of them. > Aside: It's a confusing artifact of the mount CLI that these options > control who/when but are passed to the mount command in the same way the > other options are. Yes, slightly. Actually most of these options are just ignored on the command line. They only have an affect in /etc/fstab. The right behavior of mount(8) would probably be to error out on these options, since they make no sense on the command line. But this is not a kernel issue. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
Miklos Szeredi wrote: Some mount options are never passed to the kernel, and thus can't appear in /proc/mounts. Examples include user, users, and _netdev for NFS. These options control *who* may mount and *when* to mount. They are not a property of the mount itself and are not added to /etc/mtab. There's a "user=ID" option that is added to /etc/mtab in case of user mounts. This identifies the owner of the mount, so that it can be unmounted by that user. There are patches in -mm that enable the kernel to store this info. Do you have other examples in mind? [no]quota comes to mind; also auto, [no]owner, [no]group, and quiet/loud, but these may fall into the same category you mention above. Aside: It's a confusing artifact of the mount CLI that these options control who/when but are passed to the mount command in the same way the other options are. begin:vcard fn:Chuck Lever n:Lever;Chuck org:Oracle Corporation;Corporate Architecture: Linux Projects Group adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA title:Principal Member of Staff tel;work:+1 248 614 5091 x-mozilla-html:FALSE version:2.1 end:vcard
Re: request for patches: showing mount options
> Some mount options are never passed to the kernel, and thus can't appear > in /proc/mounts. Examples include user, users, and _netdev for NFS. These options control *who* may mount and *when* to mount. They are not a property of the mount itself and are not added to /etc/mtab. There's a "user=ID" option that is added to /etc/mtab in case of user mounts. This identifies the owner of the mount, so that it can be unmounted by that user. There are patches in -mm that enable the kernel to store this info. Do you have other examples in mind? Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
Miklos: Some mount options are never passed to the kernel, and thus can't appear in /proc/mounts. Examples include user, users, and _netdev for NFS. Miklos Szeredi wrote: [please consider pruning the CC list if discussing some aspect, which doesn't concern all] I've done an audit of all filesystems with regards to showing mount options in /proc//mounts. Unfortunately most of them show none or only a part of all accepted options (for details see list of filesystems at the end of the mail). This is currently not a big problem, because mount(8) stores the given options in /etc/mtab. However we want to get rid of mtab, and this requires, that the option showing be fixed up. It would be easiest if this was done by the VFS instead of having to deal with it in filesystems. However there are differences in how filesytems handle options during mount and remount, and it would be impossible to take this into account in all cases. If you are CC-ed, and responsible for one of these filesystems, please take a moment to fully implement the ->show_options() method. In most cases it should be an easy task. If for some reason you are unable to do this, please let me know and I'll fix it up. Here are some guidelines for showing options. I'll also add these to Documentation/filesystems/vfs.txt + If a filesystem accepts mount options, it must define show_options() + to show all the currently active options. The rules are: + + - options MUST be shown which are not default or their values differ + from the default + + - options MAY be shown which are enabled by default or have their + default value + + Options used only internally between a mount helper and the kernel + (such as file descriptors), or which only have an effect during the + mounting (such as ones controlling the creation of a journal) are exempt + from the above rules. Thanks, Miklos --- legend: all - fs has options, but doesn't define ->show_options() some - fs defines ->show_options(), but some options are not shown noopt - fs does not have options good - fs shows all options patch - I have a patch 9p some adfsall (maintainer?) affsall afs all autofs all autofs4 some befsall bfs noopt cifssome (odd parser) codanoopt configfsnoopt cramfs noopt debugfs noopt devpts patch ecryptfssome efs noopt ext2patch ext3patch ext4patch fat some freevxfsnoopt fusepatch gfs2good hfs good hfsplus good hostfs patch hpfsall hppfs noopt hugetlbfs all isofs all (maintainer?) jffs2 noopt jfs some minix noopt msdos ->fat ncpfs all (FS_BINARY_MOUNTDATA?) nfs some nfsdnoopt ntfsgood (odd parser) ocfs2 all openpromfs noopt procnoopt qnx4noopt ramfs noopt reiserfsall romfs noopt smbfs good (odd parser) (maintainer?) sysfs noopt sysvnoopt udf all ufs all vfat->fat xfs some (odd parser) mm/shmem.cpatch drivers/oprofile/oprofilefs.c noopt drivers/infiniband/hw/ipath/ipath_fs.cnoopt drivers/misc/ibmasm/ibmasmfs.cnoopt drivers/usb/core (usbfs) noopt drivers/usb/gadget (gadgetfs) noopt drivers/isdn/capi/capifs.cnoopt kernel/cpuset.c noopt fs/binfmt_misc.c noopt net/sunrpc/rpc_pipe.c noopt arch/powerpc/platforms/cell/spufs all arch/s390/hypfs all ipc/mqueue.c noopt security (securityfs) noopt security/selinux/selinuxfs.c noopt in -mm: reiser4some (odd parser) kernel/container.c good (odd parser) - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html begin:vcard fn:Chuck Lever n:Lever;Chuck org:Oracle Corporation;Corporate Architecture: Linux Projects Group adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA title:Principal Member of Staff tel;work:+1 248 614 5091 x-mozilla-html:FALSE version:2.1 end:vcard
Re: request for patches: showing mount options
> cifs and nfs (probably others) have some mount options which are mount > order dependent ie may be invalid or ignored when you have more than > one mount to the same server, or mount the same resource in two places > with different options. In the long run, at least for cifs, we may be > able to better handle a user mounting to the same server twice with > e.g. different security options (authentication, packet signing ...), > but in the meantime are there any thoughts on whether those type of > mount options should be displayed differently I think they should be displayed normally, just as all the other options. If an option is shared by multiple mounts, that option should be displayed for all of them. This is similar to the case of per-mount vs. per-superblock options, which aren't separated either. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
cifs and nfs (probably others) have some mount options which are mount order dependent ie may be invalid or ignored when you have more than one mount to the same server, or mount the same resource in two places with different options. In the long run, at least for cifs, we may be able to better handle a user mounting to the same server twice with e.g. different security options (authentication, packet signing ...), but in the meantime are there any thoughts on whether those type of mount options should be displayed differently On 7/27/07, Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > all - fs has options, but doesn't define ->show_options() > > some - fs defines ->show_options(), but some options are not shown > > noopt - fs does not have options > > good - fs shows all options > > patch - I have a patch > > [...] > > > > autofs all > > > > I'm not sure I understand this. > > How does autofs show it's options without a ->show_options method? > > It doesn't. The "all" means, all of them need to be added to > ->show_options(), not that all are shown. > > I can see now that this is slightly confusing, sorry. > > So the ones that need attention are "all" and "some". The others are > fine in theory. Of course I may have missed something. > > > > autofs4 some > > > > OK, uid and gid aren't shown. > > That should be straight forward to fix. > > What's your time frame for this? > > ASAP ;) > > 2.6.24 would be a nice, but it won't be easy... > > Miklos > -- Thanks, Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
> all - fs has options, but doesn't define ->show_options() > some - fs defines ->show_options(), but some options are not shown > noopt - fs does not have options > good - fs shows all options > patch - I have a patch [...] > > autofs all > > I'm not sure I understand this. > How does autofs show it's options without a ->show_options method? It doesn't. The "all" means, all of them need to be added to ->show_options(), not that all are shown. I can see now that this is slightly confusing, sorry. So the ones that need attention are "all" and "some". The others are fine in theory. Of course I may have missed something. > > autofs4 some > > OK, uid and gid aren't shown. > That should be straight forward to fix. > What's your time frame for this? ASAP ;) 2.6.24 would be a nice, but it won't be easy... Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
On Fri, 2007-07-27 at 15:45 +0200, Miklos Szeredi wrote: > [please consider pruning the CC list if discussing some aspect, which > doesn't concern all] > > I've done an audit of all filesystems with regards to showing mount > options in /proc//mounts. Unfortunately most of them show none > or only a part of all accepted options (for details see list of > filesystems at the end of the mail). > > This is currently not a big problem, because mount(8) stores the given > options in /etc/mtab. However we want to get rid of mtab, and this > requires, that the option showing be fixed up. > > It would be easiest if this was done by the VFS instead of having to > deal with it in filesystems. However there are differences in how > filesytems handle options during mount and remount, and it would be > impossible to take this into account in all cases. > > If you are CC-ed, and responsible for one of these filesystems, please > take a moment to fully implement the ->show_options() method. In most > cases it should be an easy task. > > If for some reason you are unable to do this, please let me know and > I'll fix it up. > > Here are some guidelines for showing options. I'll also add these to > Documentation/filesystems/vfs.txt > > + If a filesystem accepts mount options, it must define show_options() > + to show all the currently active options. The rules are: > + > + - options MUST be shown which are not default or their values differ > + from the default > + > + - options MAY be shown which are enabled by default or have their > + default value > + > + Options used only internally between a mount helper and the kernel > + (such as file descriptors), or which only have an effect during the > + mounting (such as ones controlling the creation of a journal) are exempt > + from the above rules. > > Thanks, > Miklos > > --- > legend: > > all - fs has options, but doesn't define ->show_options() > some - fs defines ->show_options(), but some options are not shown > noopt - fs does not have options > good - fs shows all options > patch - I have a patch > > > 9p some > adfsall (maintainer?) > affsall > afs all > autofs all I'm not sure I understand this. How does autofs show it's options without a ->show_options method? > autofs4 some OK, uid and gid aren't shown. That should be straight forward to fix. What's your time frame for this? Ian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
> What do you consider the best example so far of a kernel module's > equivalent of "parse_mount_options" (handling a mix of options of > different types) and show_options. For example gfs2 is pretty good. It has lots of different type of options, and it handles them in remount as well as mount. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
What do you consider the best example so far of a kernel module's equivalent of "parse_mount_options" (handling a mix of options of different types) and show_options. On 7/27/07, Miklos Szeredi <[EMAIL PROTECTED]> wrote: > [please consider pruning the CC list if discussing some aspect, which > doesn't concern all] > > I've done an audit of all filesystems with regards to showing mount > options in /proc//mounts. Unfortunately most of them show none > or only a part of all accepted options (for details see list of > filesystems at the end of the mail). > > This is currently not a big problem, because mount(8) stores the given > options in /etc/mtab. However we want to get rid of mtab, and this > requires, that the option showing be fixed up. > > It would be easiest if this was done by the VFS instead of having to > deal with it in filesystems. However there are differences in how > filesytems handle options during mount and remount, and it would be > impossible to take this into account in all cases. > > If you are CC-ed, and responsible for one of these filesystems, please > take a moment to fully implement the ->show_options() method. In most > cases it should be an easy task. > > If for some reason you are unable to do this, please let me know and > I'll fix it up. > > Here are some guidelines for showing options. I'll also add these to > Documentation/filesystems/vfs.txt > > + If a filesystem accepts mount options, it must define show_options() > + to show all the currently active options. The rules are: > + > + - options MUST be shown which are not default or their values differ > + from the default > + > + - options MAY be shown which are enabled by default or have their > + default value > + > + Options used only internally between a mount helper and the kernel > + (such as file descriptors), or which only have an effect during the > + mounting (such as ones controlling the creation of a journal) are exempt > + from the above rules. > > Thanks, > Miklos > > --- > legend: > > all - fs has options, but doesn't define ->show_options() > some - fs defines ->show_options(), but some options are not shown > noopt - fs does not have options > good - fs shows all options > patch - I have a patch > > > 9p some > adfsall (maintainer?) > affsall > afs all > autofs all > autofs4 some > befsall > bfs noopt > cifssome (odd parser) > codanoopt > configfsnoopt > cramfs noopt > debugfs noopt > devpts patch > ecryptfssome > efs noopt > ext2patch > ext3patch > ext4patch > fat some > freevxfsnoopt > fusepatch > gfs2good > hfs good > hfsplus good > hostfs patch > hpfsall > hppfs noopt > hugetlbfs all > isofs all (maintainer?) > jffs2 noopt > jfs some > minix noopt > msdos ->fat > ncpfs all (FS_BINARY_MOUNTDATA?) > nfs some > nfsdnoopt > ntfsgood (odd parser) > ocfs2 all > openpromfs noopt > procnoopt > qnx4noopt > ramfs noopt > reiserfsall > romfs noopt > smbfs good (odd parser) (maintainer?) > sysfs noopt > sysvnoopt > udf all > ufs all > vfat->fat > xfs some (odd parser) > > mm/shmem.cpatch > drivers/oprofile/oprofilefs.c noopt > drivers/infiniband/hw/ipath/ipath_fs.cnoopt > drivers/misc/ibmasm/ibmasmfs.cnoopt > drivers/usb/core (usbfs) noopt > drivers/usb/gadget (gadgetfs) noopt > drivers/isdn/capi/capifs.cnoopt > kernel/cpuset.c noopt > fs/binfmt_misc.c noopt > net/sunrpc/rpc_pipe.c noopt > arch/powerpc/platforms/cell/spufs all > arch/s390/hypfs all > ipc/mqueue.c noopt > security (securityfs) noopt > security/selinux/selinuxfs.c noopt > > in -mm: > > reiser4some (odd parser) > kernel/container.c good (odd parser) > -- Thanks, Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
What do you consider the best example so far of a kernel module's equivalent of parse_mount_options (handling a mix of options of different types) and show_options. For example gfs2 is pretty good. It has lots of different type of options, and it handles them in remount as well as mount. Miklos - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
On Fri, 2007-07-27 at 15:45 +0200, Miklos Szeredi wrote: [please consider pruning the CC list if discussing some aspect, which doesn't concern all] I've done an audit of all filesystems with regards to showing mount options in /proc/pid/mounts. Unfortunately most of them show none or only a part of all accepted options (for details see list of filesystems at the end of the mail). This is currently not a big problem, because mount(8) stores the given options in /etc/mtab. However we want to get rid of mtab, and this requires, that the option showing be fixed up. It would be easiest if this was done by the VFS instead of having to deal with it in filesystems. However there are differences in how filesytems handle options during mount and remount, and it would be impossible to take this into account in all cases. If you are CC-ed, and responsible for one of these filesystems, please take a moment to fully implement the -show_options() method. In most cases it should be an easy task. If for some reason you are unable to do this, please let me know and I'll fix it up. Here are some guidelines for showing options. I'll also add these to Documentation/filesystems/vfs.txt + If a filesystem accepts mount options, it must define show_options() + to show all the currently active options. The rules are: + + - options MUST be shown which are not default or their values differ + from the default + + - options MAY be shown which are enabled by default or have their + default value + + Options used only internally between a mount helper and the kernel + (such as file descriptors), or which only have an effect during the + mounting (such as ones controlling the creation of a journal) are exempt + from the above rules. Thanks, Miklos --- legend: all - fs has options, but doesn't define -show_options() some - fs defines -show_options(), but some options are not shown noopt - fs does not have options good - fs shows all options patch - I have a patch 9p some adfsall (maintainer?) affsall afs all autofs all I'm not sure I understand this. How does autofs show it's options without a -show_options method? autofs4 some OK, uid and gid aren't shown. That should be straight forward to fix. What's your time frame for this? Ian - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
all - fs has options, but doesn't define -show_options() some - fs defines -show_options(), but some options are not shown noopt - fs does not have options good - fs shows all options patch - I have a patch [...] autofs all I'm not sure I understand this. How does autofs show it's options without a -show_options method? It doesn't. The all means, all of them need to be added to -show_options(), not that all are shown. I can see now that this is slightly confusing, sorry. So the ones that need attention are all and some. The others are fine in theory. Of course I may have missed something. autofs4 some OK, uid and gid aren't shown. That should be straight forward to fix. What's your time frame for this? ASAP ;) 2.6.24 would be a nice, but it won't be easy... Miklos - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
cifs and nfs (probably others) have some mount options which are mount order dependent ie may be invalid or ignored when you have more than one mount to the same server, or mount the same resource in two places with different options. In the long run, at least for cifs, we may be able to better handle a user mounting to the same server twice with e.g. different security options (authentication, packet signing ...), but in the meantime are there any thoughts on whether those type of mount options should be displayed differently I think they should be displayed normally, just as all the other options. If an option is shared by multiple mounts, that option should be displayed for all of them. This is similar to the case of per-mount vs. per-superblock options, which aren't separated either. Miklos - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
What do you consider the best example so far of a kernel module's equivalent of parse_mount_options (handling a mix of options of different types) and show_options. On 7/27/07, Miklos Szeredi [EMAIL PROTECTED] wrote: [please consider pruning the CC list if discussing some aspect, which doesn't concern all] I've done an audit of all filesystems with regards to showing mount options in /proc/pid/mounts. Unfortunately most of them show none or only a part of all accepted options (for details see list of filesystems at the end of the mail). This is currently not a big problem, because mount(8) stores the given options in /etc/mtab. However we want to get rid of mtab, and this requires, that the option showing be fixed up. It would be easiest if this was done by the VFS instead of having to deal with it in filesystems. However there are differences in how filesytems handle options during mount and remount, and it would be impossible to take this into account in all cases. If you are CC-ed, and responsible for one of these filesystems, please take a moment to fully implement the -show_options() method. In most cases it should be an easy task. If for some reason you are unable to do this, please let me know and I'll fix it up. Here are some guidelines for showing options. I'll also add these to Documentation/filesystems/vfs.txt + If a filesystem accepts mount options, it must define show_options() + to show all the currently active options. The rules are: + + - options MUST be shown which are not default or their values differ + from the default + + - options MAY be shown which are enabled by default or have their + default value + + Options used only internally between a mount helper and the kernel + (such as file descriptors), or which only have an effect during the + mounting (such as ones controlling the creation of a journal) are exempt + from the above rules. Thanks, Miklos --- legend: all - fs has options, but doesn't define -show_options() some - fs defines -show_options(), but some options are not shown noopt - fs does not have options good - fs shows all options patch - I have a patch 9p some adfsall (maintainer?) affsall afs all autofs all autofs4 some befsall bfs noopt cifssome (odd parser) codanoopt configfsnoopt cramfs noopt debugfs noopt devpts patch ecryptfssome efs noopt ext2patch ext3patch ext4patch fat some freevxfsnoopt fusepatch gfs2good hfs good hfsplus good hostfs patch hpfsall hppfs noopt hugetlbfs all isofs all (maintainer?) jffs2 noopt jfs some minix noopt msdos -fat ncpfs all (FS_BINARY_MOUNTDATA?) nfs some nfsdnoopt ntfsgood (odd parser) ocfs2 all openpromfs noopt procnoopt qnx4noopt ramfs noopt reiserfsall romfs noopt smbfs good (odd parser) (maintainer?) sysfs noopt sysvnoopt udf all ufs all vfat-fat xfs some (odd parser) mm/shmem.cpatch drivers/oprofile/oprofilefs.c noopt drivers/infiniband/hw/ipath/ipath_fs.cnoopt drivers/misc/ibmasm/ibmasmfs.cnoopt drivers/usb/core (usbfs) noopt drivers/usb/gadget (gadgetfs) noopt drivers/isdn/capi/capifs.cnoopt kernel/cpuset.c noopt fs/binfmt_misc.c noopt net/sunrpc/rpc_pipe.c noopt arch/powerpc/platforms/cell/spufs all arch/s390/hypfs all ipc/mqueue.c noopt security (securityfs) noopt security/selinux/selinuxfs.c noopt in -mm: reiser4some (odd parser) kernel/container.c good (odd parser) -- Thanks, Steve - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
cifs and nfs (probably others) have some mount options which are mount order dependent ie may be invalid or ignored when you have more than one mount to the same server, or mount the same resource in two places with different options. In the long run, at least for cifs, we may be able to better handle a user mounting to the same server twice with e.g. different security options (authentication, packet signing ...), but in the meantime are there any thoughts on whether those type of mount options should be displayed differently On 7/27/07, Miklos Szeredi [EMAIL PROTECTED] wrote: all - fs has options, but doesn't define -show_options() some - fs defines -show_options(), but some options are not shown noopt - fs does not have options good - fs shows all options patch - I have a patch [...] autofs all I'm not sure I understand this. How does autofs show it's options without a -show_options method? It doesn't. The all means, all of them need to be added to -show_options(), not that all are shown. I can see now that this is slightly confusing, sorry. So the ones that need attention are all and some. The others are fine in theory. Of course I may have missed something. autofs4 some OK, uid and gid aren't shown. That should be straight forward to fix. What's your time frame for this? ASAP ;) 2.6.24 would be a nice, but it won't be easy... Miklos -- Thanks, Steve - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
Miklos: Some mount options are never passed to the kernel, and thus can't appear in /proc/mounts. Examples include user, users, and _netdev for NFS. Miklos Szeredi wrote: [please consider pruning the CC list if discussing some aspect, which doesn't concern all] I've done an audit of all filesystems with regards to showing mount options in /proc/pid/mounts. Unfortunately most of them show none or only a part of all accepted options (for details see list of filesystems at the end of the mail). This is currently not a big problem, because mount(8) stores the given options in /etc/mtab. However we want to get rid of mtab, and this requires, that the option showing be fixed up. It would be easiest if this was done by the VFS instead of having to deal with it in filesystems. However there are differences in how filesytems handle options during mount and remount, and it would be impossible to take this into account in all cases. If you are CC-ed, and responsible for one of these filesystems, please take a moment to fully implement the -show_options() method. In most cases it should be an easy task. If for some reason you are unable to do this, please let me know and I'll fix it up. Here are some guidelines for showing options. I'll also add these to Documentation/filesystems/vfs.txt + If a filesystem accepts mount options, it must define show_options() + to show all the currently active options. The rules are: + + - options MUST be shown which are not default or their values differ + from the default + + - options MAY be shown which are enabled by default or have their + default value + + Options used only internally between a mount helper and the kernel + (such as file descriptors), or which only have an effect during the + mounting (such as ones controlling the creation of a journal) are exempt + from the above rules. Thanks, Miklos --- legend: all - fs has options, but doesn't define -show_options() some - fs defines -show_options(), but some options are not shown noopt - fs does not have options good - fs shows all options patch - I have a patch 9p some adfsall (maintainer?) affsall afs all autofs all autofs4 some befsall bfs noopt cifssome (odd parser) codanoopt configfsnoopt cramfs noopt debugfs noopt devpts patch ecryptfssome efs noopt ext2patch ext3patch ext4patch fat some freevxfsnoopt fusepatch gfs2good hfs good hfsplus good hostfs patch hpfsall hppfs noopt hugetlbfs all isofs all (maintainer?) jffs2 noopt jfs some minix noopt msdos -fat ncpfs all (FS_BINARY_MOUNTDATA?) nfs some nfsdnoopt ntfsgood (odd parser) ocfs2 all openpromfs noopt procnoopt qnx4noopt ramfs noopt reiserfsall romfs noopt smbfs good (odd parser) (maintainer?) sysfs noopt sysvnoopt udf all ufs all vfat-fat xfs some (odd parser) mm/shmem.cpatch drivers/oprofile/oprofilefs.c noopt drivers/infiniband/hw/ipath/ipath_fs.cnoopt drivers/misc/ibmasm/ibmasmfs.cnoopt drivers/usb/core (usbfs) noopt drivers/usb/gadget (gadgetfs) noopt drivers/isdn/capi/capifs.cnoopt kernel/cpuset.c noopt fs/binfmt_misc.c noopt net/sunrpc/rpc_pipe.c noopt arch/powerpc/platforms/cell/spufs all arch/s390/hypfs all ipc/mqueue.c noopt security (securityfs) noopt security/selinux/selinuxfs.c noopt in -mm: reiser4some (odd parser) kernel/container.c good (odd parser) - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html begin:vcard fn:Chuck Lever n:Lever;Chuck org:Oracle Corporation;Corporate Architecture: Linux Projects Group adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA title:Principal Member of Staff tel;work:+1 248 614 5091 x-mozilla-html:FALSE version:2.1 end:vcard
Re: request for patches: showing mount options
Miklos Szeredi wrote: Some mount options are never passed to the kernel, and thus can't appear in /proc/mounts. Examples include user, users, and _netdev for NFS. These options control *who* may mount and *when* to mount. They are not a property of the mount itself and are not added to /etc/mtab. There's a user=ID option that is added to /etc/mtab in case of user mounts. This identifies the owner of the mount, so that it can be unmounted by that user. There are patches in -mm that enable the kernel to store this info. Do you have other examples in mind? [no]quota comes to mind; also auto, [no]owner, [no]group, and quiet/loud, but these may fall into the same category you mention above. Aside: It's a confusing artifact of the mount CLI that these options control who/when but are passed to the mount command in the same way the other options are. begin:vcard fn:Chuck Lever n:Lever;Chuck org:Oracle Corporation;Corporate Architecture: Linux Projects Group adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA title:Principal Member of Staff tel;work:+1 248 614 5091 x-mozilla-html:FALSE version:2.1 end:vcard
Re: request for patches: showing mount options
Some mount options are never passed to the kernel, and thus can't appear in /proc/mounts. Examples include user, users, and _netdev for NFS. These options control *who* may mount and *when* to mount. They are not a property of the mount itself and are not added to /etc/mtab. There's a user=ID option that is added to /etc/mtab in case of user mounts. This identifies the owner of the mount, so that it can be unmounted by that user. There are patches in -mm that enable the kernel to store this info. Do you have other examples in mind? Miklos - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request for patches: showing mount options
Some mount options are never passed to the kernel, and thus can't appear in /proc/mounts. Examples include user, users, and _netdev for NFS. These options control *who* may mount and *when* to mount. They are not a property of the mount itself and are not added to /etc/mtab. There's a user=ID option that is added to /etc/mtab in case of user mounts. This identifies the owner of the mount, so that it can be unmounted by that user. There are patches in -mm that enable the kernel to store this info. Do you have other examples in mind? [no]quota comes to mind; These are passed to the kernel. also auto, This controls when a filesystem is mounted, same category as '_netdev' [no]owner, [no]group, These control who can mount the filesystem, same category as 'user' and 'users' quiet/loud, I can't find these in the manual as universal options. Quiet is defined for a couple of filesystems but with different meaning for each of them. Aside: It's a confusing artifact of the mount CLI that these options control who/when but are passed to the mount command in the same way the other options are. Yes, slightly. Actually most of these options are just ignored on the command line. They only have an affect in /etc/fstab. The right behavior of mount(8) would probably be to error out on these options, since they make no sense on the command line. But this is not a kernel issue. Miklos - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
