Re: Reason why "nocache" option is not displayed in "mount"?
On Mon, Mar 11, 2024 at 09:03:38AM +0100, Alexander Leidinger wrote: > Am 2024-03-10 22:57, schrieb Konstantin Belousov: > > > We are already low on the free bits in the flags, even after expanding > > them > > to 64bit. More, there are useful common fs services continuously > > consuming > > that flags, e.g. the recent NFS TLS options. > > > > I object against using the flags for absolutely not important things, > > like > > this nullfs "cache" option. > > > > In long term, we would have to export nmount(2) strings since bits in > > flags are finite, but I prefer to delay it as much as possible. > > Why do you want to delay this? Personal priorities, or technical reasons? Because it is a lot of work which is currently not needed and where I will need to participate.
Re: Reason why "nocache" option is not displayed in "mount"?
Am 2024-03-10 22:57, schrieb Konstantin Belousov: We are already low on the free bits in the flags, even after expanding them to 64bit. More, there are useful common fs services continuously consuming that flags, e.g. the recent NFS TLS options. I object against using the flags for absolutely not important things, like this nullfs "cache" option. In long term, we would have to export nmount(2) strings since bits in flags are finite, but I prefer to delay it as much as possible. Why do you want to delay this? Personal priorities, or technical reasons? Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature
Re: Reason why "nocache" option is not displayed in "mount"?
On Sun, Mar 10, 2024 at 09:50:51PM +, Kirk McKusick wrote: > > Date: Sun, 10 Mar 2024 19:21:54 +0200 > > From: Konstantin Belousov > > To: Kirk McKusick > > Cc: curr...@freebsd.org > > Subject: Re: Reason why "nocache" option is not displayed in "mount"? > > > > On Sun, Mar 10, 2024 at 01:53:05AM +, Kirk McKusick wrote: > >> The issue has to do with how flags are defined in mount.h. > >> Specifically there are the flags that are externally visible > >> (prefixed with MNT_) and those that are for internal use > >> (prefixed with MNTK_, the K standing for KERNEL). If it > >> is desirable to have MNTK_NULL_NOCACHE visible, then it > >> should be renamed to MNT_NULL_CACHE, added to MNT_VISFLAGMASK, > >> and listed in MNTOPT_NAMES. It probably belongs in the set > >> described as `Flags set by internal operations, but visible > >> to the user.' With this change, it will be displayed by > >> the mount command and show up in the statfs flags. > > > > There is no MNTK_NULL_NOCACHE flag in mnt_kern_flags. > > > > When userspace communicates the "cache" or "nocache" option to the > > VFS_MOUNT() op for nullfs, it passes plain C string using the nmount(2) > > system call. The strings are explicitly queried by nullfs_mount(), mixed > > with the "default" sysctl, and then the nullfs-mount specific data flag > > is set, in mp->mnt_data.null_flag. > > > > There is no space in the struct statfs for ABI extension. > > The getfsstat(2) system call cannot report arbitrary fs-specific options. > > > > If somebody wants to uniformilly report fs-specific options, instead of > > scattered fs-specific hacks like MNT_SOFTDEP/MNT_GJOURNAL (UFS) and > > nfsstat -m (nfsclient), then some extension for nmount(2) is due, > > say MNT_QUERY_OP, which should be passed down to VFS_MOUNT() and back. > > As you note there are some filesystem specific flags already in > mnt_flag that get copied to the statfs f_flags field. My point is > that the NOCACHE flag could be moved to mnt_flag and made visible > in the f_flags field. While it is currently specific to nullfs, it > might be useful to implement it in other filesystems. We are already low on the free bits in the flags, even after expanding them to 64bit. More, there are useful common fs services continuously consuming that flags, e.g. the recent NFS TLS options. I object against using the flags for absolutely not important things, like this nullfs "cache" option. In long term, we would have to export nmount(2) strings since bits in flags are finite, but I prefer to delay it as much as possible.
Re: Reason why "nocache" option is not displayed in "mount"?
> Date: Sun, 10 Mar 2024 19:21:54 +0200 > From: Konstantin Belousov > To: Kirk McKusick > Cc: curr...@freebsd.org > Subject: Re: Reason why "nocache" option is not displayed in "mount"? > > On Sun, Mar 10, 2024 at 01:53:05AM +, Kirk McKusick wrote: >> The issue has to do with how flags are defined in mount.h. >> Specifically there are the flags that are externally visible >> (prefixed with MNT_) and those that are for internal use >> (prefixed with MNTK_, the K standing for KERNEL). If it >> is desirable to have MNTK_NULL_NOCACHE visible, then it >> should be renamed to MNT_NULL_CACHE, added to MNT_VISFLAGMASK, >> and listed in MNTOPT_NAMES. It probably belongs in the set >> described as `Flags set by internal operations, but visible >> to the user.' With this change, it will be displayed by >> the mount command and show up in the statfs flags. > > There is no MNTK_NULL_NOCACHE flag in mnt_kern_flags. > > When userspace communicates the "cache" or "nocache" option to the > VFS_MOUNT() op for nullfs, it passes plain C string using the nmount(2) > system call. The strings are explicitly queried by nullfs_mount(), mixed > with the "default" sysctl, and then the nullfs-mount specific data flag > is set, in mp->mnt_data.null_flag. > > There is no space in the struct statfs for ABI extension. > The getfsstat(2) system call cannot report arbitrary fs-specific options. > > If somebody wants to uniformilly report fs-specific options, instead of > scattered fs-specific hacks like MNT_SOFTDEP/MNT_GJOURNAL (UFS) and > nfsstat -m (nfsclient), then some extension for nmount(2) is due, > say MNT_QUERY_OP, which should be passed down to VFS_MOUNT() and back. As you note there are some filesystem specific flags already in mnt_flag that get copied to the statfs f_flags field. My point is that the NOCACHE flag could be moved to mnt_flag and made visible in the f_flags field. While it is currently specific to nullfs, it might be useful to implement it in other filesystems. Kirk McKusick
Re: Reason why "nocache" option is not displayed in "mount"?
On Sun, Mar 10, 2024 at 01:53:05AM +, Kirk McKusick wrote: > The issue has to do with how flags are defined in mount.h. > Specifically there are the flags that are externally visible > (prefixed with MNT_) and those that are for internal use > (prefixed with MNTK_, the K standing for KERNEL). If it > is desirable to have MNTK_NULL_NOCACHE visible, then it > should be renamed to MNT_NULL_CACHE, added to MNT_VISFLAGMASK, > and listed in MNTOPT_NAMES. It probably belongs in the set > described as `Flags set by internal operations, but visible > to the user.' With this change, it will be displayed by > the mount command and show up in the statfs flags. There is no MNTK_NULL_NOCACHE flag in mnt_kern_flags. When userspace communicates the "cache" or "nocache" option to the VFS_MOUNT() op for nullfs, it passes plain C string using the nmount(2) system call. The strings are explicitly queried by nullfs_mount(), mixed with the "default" sysctl, and then the nullfs-mount specific data flag is set, in mp->mnt_data.null_flag. There is no space in the struct statfs for ABI extension. The getfsstat(2) system call cannot report arbitrary fs-specific options. If somebody wants to uniformilly report fs-specific options, instead of scattered fs-specific hacks like MNT_SOFTDEP/MNT_GJOURNAL (UFS) and nfsstat -m (nfsclient), then some extension for nmount(2) is due, say MNT_QUERY_OP, which should be passed down to VFS_MOUNT() and back.
Re: Reason why "nocache" option is not displayed in "mount"?
Kirk McKusick wrote on Date: Sun, 10 Mar 2024 01:53:05 UTC : > The issue has to do with how flags are defined in mount.h. > Specifically there are the flags that are externally visible > (prefixed with MNT_) and those that are for internal use > (prefixed with MNTK_, the K standing for KERNEL). If it > is desirable to have MNTK_NULL_NOCACHE visible, then it > should be renamed to MNT_NULL_CACHE, added to MNT_VISFLAGMASK, > and listed in MNTOPT_NAMES. It probably belongs in the set > described as `Flags set by internal operations, but visible > to the user.' With this change, it will be displayed by > the mount command and show up in the statfs flags. -o nocache appears to be mount_nullfs specific: man mount_nullfs reports: The options are as follows: -o Options are specified with a -o flag followed by a comma separated string of options. See the mount(8) man page for possible options and their meanings. Additionally the following option is supported: nocache Disable metadata caching in the null layer. Some lower- layer file systems may force this option. Depending on the access pattern, this may result in increased lock contention. There is also the recent addition to main of: QUOTE +The +.Dv vfs.nullfs.cache_vnodes +sysctl specifies global default for mount-specific cache/nocache option. END QUOTE The vfs.nullfs.cache_vnodes related commits listed a 1 week MFC. Now -o cache is an option as well, in order to cover both defaults being possible. (While it is not limited to what initiated the additions, that initiation is associated with some ZFS performance problem avoidance work that is going on where the caching was having negative consequences when nullfs was also in use.) kib's wording when I asked about the display-of-mode-status issue was: QUOTE Mount uses getfsstat(2) which has no knowledge of nmount(2). END QUOTE === Mark Millard marklmi at yahoo.com
Re: Reason why "nocache" option is not displayed in "mount"?
The issue has to do with how flags are defined in mount.h. Specifically there are the flags that are externally visible (prefixed with MNT_) and those that are for internal use (prefixed with MNTK_, the K standing for KERNEL). If it is desirable to have MNTK_NULL_NOCACHE visible, then it should be renamed to MNT_NULL_CACHE, added to MNT_VISFLAGMASK, and listed in MNTOPT_NAMES. It probably belongs in the set described as `Flags set by internal operations, but visible to the user.' With this change, it will be displayed by the mount command and show up in the statfs flags. Kirk McKusick
Re: Reason why "nocache" option is not displayed in "mount"?
Am 2024-03-09 15:27, schrieb Rick Macklem: On Sat, Mar 9, 2024 at 5:08 AM Alexander Leidinger wrote: Am 2024-03-09 06:07, schrieb Warner Losh: > On Thu, Mar 7, 2024 at 1:05 PM Jamie Landeg-Jones > wrote: > >> Alexander Leidinger wrote: >> >>> Hi, >>> >>> what is the reason why "nocache" is not displayed in the output of >>> "mount" for nullfs options? >> >> Good catch. I also notice that "hidden" is not shown either. >> >> I guess that as for some time, "nocache" was a "secret" option, no-one >> update "mount" to display it? > > So a couple of things to know. > > First, there's a list of known options. These are converted to a > bitmask. This is then decoded and reported by mount. The other strings > are passed to the filesystem directly. They decode it and do things, > but they don't export them (that I can find). I believe that's why they > aren't reported with 'mount'. There's a couple of other options in > /etc/fstab that are pseudo options too. That's the technical explanation why it doesn't work. I'm a step further since initial mail, I even had a look at the code and know that nocache is recorded in a nullfs private flag and that the userland can not access this (mount looks at struct statfs which doesn't provide info to this and some other things). My question was targeted more in the direction if there is a conceptual reason or if it was an oversight that it is not displayed. I admit that this was lost in translation... Regarding the issue of not being able to see all options which are in effect for a given mount point (not specific to nocache): I consider this to be a bug. Pseudo options like "late" or "noauto" in fstab which don't make sense to use when you use mount(8) a FS by hand, I do not consider here. As a data point, I added the "-m"option to nfsstat(1) so that all the nfs related options get displayed. Part of the problem is that this will be file system specific, since nmount() defers processing options to the file systems. There exists values for a lot of the mount opions which are not displayed. For example the nocache option for nullfs is MNTK_NULL_NOCACHE in https://cgit.freebsd.org/src/tree/sys/sys/mount.h#n515 This may not be useable as is, but I use it to show that there are already bits public about it, just not in the proper place to be useful to the userland. Even FS specific options could be set as part of statfs (by letting the FS set them in struct statfs). Or there could be a per-mount callback / ioctl / whatever which provides the options in some way to the userland if requested. So we either have something which could be used but requires some interface to let a FS set a value somewhere, or if this is a too gross hack, we would need to come up with a new interface to query this info. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature
Re: Reason why "nocache" option is not displayed in "mount"?
On Sat, Mar 9, 2024 at 5:08 AM Alexander Leidinger wrote: > > Am 2024-03-09 06:07, schrieb Warner Losh: > > > On Thu, Mar 7, 2024 at 1:05 PM Jamie Landeg-Jones > > wrote: > > > >> Alexander Leidinger wrote: > >> > >>> Hi, > >>> > >>> what is the reason why "nocache" is not displayed in the output of > >>> "mount" for nullfs options? > >> > >> Good catch. I also notice that "hidden" is not shown either. > >> > >> I guess that as for some time, "nocache" was a "secret" option, no-one > >> update "mount" to display it? > > > > So a couple of things to know. > > > > First, there's a list of known options. These are converted to a > > bitmask. This is then decoded and reported by mount. The other strings > > are passed to the filesystem directly. They decode it and do things, > > but they don't export them (that I can find). I believe that's why they > > aren't reported with 'mount'. There's a couple of other options in > > /etc/fstab that are pseudo options too. > > That's the technical explanation why it doesn't work. I'm a step further > since initial mail, I even had a look at the code and know that nocache > is recorded in a nullfs private flag and that the userland can not > access this (mount looks at struct statfs which doesn't provide info to > this and some other things). > > My question was targeted more in the direction if there is a conceptual > reason or if it was an oversight that it is not displayed. I admit that > this was lost in translation... > > Regarding the issue of not being able to see all options which are in > effect for a given mount point (not specific to nocache): I consider > this to be a bug. > Pseudo options like "late" or "noauto" in fstab which don't make sense > to use when you use mount(8) a FS by hand, I do not consider here. As a data point, I added the "-m"option to nfsstat(1) so that all the nfs related options get displayed. Part of the problem is that this will be file system specific, since nmount() defers processing options to the file systems. rick > > I'm not sure if this warrants a bug tracker item (which maybe nobody is > interested to take ownership of), or if we need to extend the man pages > with info which option will not by displayed in the output of mounted > FS, or both. > > Bye, > Alexander. > > -- > http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF
Re: Reason why "nocache" option is not displayed in "mount"?
Am 2024-03-09 06:07, schrieb Warner Losh: On Thu, Mar 7, 2024 at 1:05 PM Jamie Landeg-Jones wrote: Alexander Leidinger wrote: Hi, what is the reason why "nocache" is not displayed in the output of "mount" for nullfs options? Good catch. I also notice that "hidden" is not shown either. I guess that as for some time, "nocache" was a "secret" option, no-one update "mount" to display it? So a couple of things to know. First, there's a list of known options. These are converted to a bitmask. This is then decoded and reported by mount. The other strings are passed to the filesystem directly. They decode it and do things, but they don't export them (that I can find). I believe that's why they aren't reported with 'mount'. There's a couple of other options in /etc/fstab that are pseudo options too. That's the technical explanation why it doesn't work. I'm a step further since initial mail, I even had a look at the code and know that nocache is recorded in a nullfs private flag and that the userland can not access this (mount looks at struct statfs which doesn't provide info to this and some other things). My question was targeted more in the direction if there is a conceptual reason or if it was an oversight that it is not displayed. I admit that this was lost in translation... Regarding the issue of not being able to see all options which are in effect for a given mount point (not specific to nocache): I consider this to be a bug. Pseudo options like "late" or "noauto" in fstab which don't make sense to use when you use mount(8) a FS by hand, I do not consider here. I'm not sure if this warrants a bug tracker item (which maybe nobody is interested to take ownership of), or if we need to extend the man pages with info which option will not by displayed in the output of mounted FS, or both. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature
Re: Reason why "nocache" option is not displayed in "mount"?
On Thu, Mar 7, 2024 at 1:05 PM Jamie Landeg-Jones wrote: > Alexander Leidinger wrote: > > > Hi, > > > > what is the reason why "nocache" is not displayed in the output of > > "mount" for nullfs options? > > Good catch. I also notice that "hidden" is not shown either. > > I guess that as for some time, "nocache" was a "secret" option, no-one > update "mount" to display it? > So a couple of things to know. First, there's a list of known options. These are converted to a bitmask. This is then decoded and reported by mount. The other strings are passed to the filesystem directly. They decode it and do things, but they don't export them (that I can find). I believe that's why they aren't reported with 'mount'. There's a couple of other options in /etc/fstab that are pseudo options too. Warner
Re: Reason why "nocache" option is not displayed in "mount"?
Jamie Landeg-Jones wrote: > Good catch. I also notice that "hidden" is not shown either. Sorry, I meant mount option "ignore" not "hidden".
Re: Reason why "nocache" option is not displayed in "mount"?
Alexander Leidinger wrote: > Hi, > > what is the reason why "nocache" is not displayed in the output of > "mount" for nullfs options? Good catch. I also notice that "hidden" is not shown either. I guess that as for some time, "nocache" was a "secret" option, no-one update "mount" to display it?
Re: Reason why "nocache" option is not displayed in "mount"?
Am 2024-03-07 14:59, schrieb Christos Chatzaras: what is the reason why "nocache" is not displayed in the output of "mount" for nullfs options? # grep packages /etc/fstab.commit_leidinger_net /shared/ports/packages /space/jails/commit.leidinger.net/shared/ports/packages nullfs rw,noatime,nocache 0 0 # mount | grep commit | grep packages /shared/ports/packages on /space/jails/commit.leidinger.net/shared/ports/packages (nullfs, local, noatime, noexec, nosuid, nfsv4acls) Context: I wanted to check if poudriere is mounting with or without "nocache", and instead of reading the source I wanted to do it more quickly by looking at the mount options. In my setup, I mount the /home directory using nullfs with the nocache option to facilitate access for certain jails. The primary reason for employing nocache is due to the implementation of ZFS quotas on the main system, which do not accurately reflect changes in file usage by users within the jail unless nocache is used. When files are added or removed by a user within jail, their disk usage wasn't properly updated on the main system until I started using nocache. Based on this experience, I'm confident that applying nocache works as expected in your scenario as well. It does. The question is how to I _see_ that a mount point is _setup_ with nocache? In the above example the FS _is_ mounted with nocache, but it is _not displayed_ in the output. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature
Re: Reason why "nocache" option is not displayed in "mount"?
> what is the reason why "nocache" is not displayed in the output of "mount" > for nullfs options? > > # grep packages /etc/fstab.commit_leidinger_net > /shared/ports/packages > /space/jails/commit.leidinger.net/shared/ports/packages nullfs > rw,noatime,nocache 0 0 > > # mount | grep commit | grep packages > /shared/ports/packages on > /space/jails/commit.leidinger.net/shared/ports/packages (nullfs, local, > noatime, noexec, nosuid, nfsv4acls) > > Context: I wanted to check if poudriere is mounting with or without > "nocache", and instead of reading the source I wanted to do it more quickly > by looking at the mount options. In my setup, I mount the /home directory using nullfs with the nocache option to facilitate access for certain jails. The primary reason for employing nocache is due to the implementation of ZFS quotas on the main system, which do not accurately reflect changes in file usage by users within the jail unless nocache is used. When files are added or removed by a user within jail, their disk usage wasn't properly updated on the main system until I started using nocache. Based on this experience, I'm confident that applying nocache works as expected in your scenario as well.
Reason why "nocache" option is not displayed in "mount"?
Hi, what is the reason why "nocache" is not displayed in the output of "mount" for nullfs options? # grep packages /etc/fstab.commit_leidinger_net /shared/ports/packages /space/jails/commit.leidinger.net/shared/ports/packages nullfs rw,noatime,nocache 0 0 # mount | grep commit | grep packages /shared/ports/packages on /space/jails/commit.leidinger.net/shared/ports/packages (nullfs, local, noatime, noexec, nosuid, nfsv4acls) Context: I wanted to check if poudriere is mounting with or without "nocache", and instead of reading the source I wanted to do it more quickly by looking at the mount options. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature
