Re: Reason why "nocache" option is not displayed in "mount"?

[Mark Millard]

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"?

[Kirk McKusick]

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

RFC: should a va_bytes option be added to vn_getsize_locked()?

[Rick Macklem]

Hi,

I would like to compare va_size to va_bytes in vn_generic_copy_file_range(),
as a heuristic to check for a sparse file (only works for non-compressed
file systems).

The call to VOP_GETATTR(invp, ..) was replaced by vn_getsize_locked()
in vn_generic_copy_file_range().

To get va_bytes I can either modify the code to again use VOP_GETATTR()
or I could add an additional return argument to vn_getsize_locked().
Since vn_getsize_locked() is descibed as a first step towards not using
VOP_GETATTR() it sounds like adding an agument to vn_getsize_locked()
is not the preferred alternative, but I thought I'd ask.

Thanks for any comments, rick

Re: Boot failure, amd64 (HP EliteBook 650 G10)

[Philipp Ost]

Hi Graham,

On 3/9/24 10:52, Graham Perrin wrote:



amd64.

AFAICT the EliteBook 650 G10 was introduced around May 2023.

Does anything in the three photographs tally with a report in Bugzilla?

Any overlap with 
 for AMD Ryzen 7 CPU (Lenovo ThinkPad P16s Gen2 (AMD; Type 21K9))?


I would try booting with uart{0,1} disabled at the loader prompt. I 
stumbled upon that by chance, here: 
https://forums.freebsd.org/threads/debugging-the-boot-process.60224/ 
(the forum thread is from 2017, so the issue seems to be somewhat 
persistent ;-)).


Best of luck
Philipp

Re: Reason why "nocache" option is not displayed in "mount"?

[Alexander Leidinger]

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: Boot failure, amd64 (HP EliteBook 650 G10)

[Warner Losh]

I'd love to borrow one of these machines fir a week or so.

Warner

On Sat, Mar 9, 2024, 2:52 AM Graham Perrin  wrote:

> 
>
> amd64.
>
> AFAICT the EliteBook 650 G10 was introduced around May 2023.
>
> Does anything in the three photographs tally with a report in Bugzilla?
>
> Any overlap with
> 
>
> for AMD Ryzen 7 CPU (Lenovo ThinkPad P16s Gen2 (AMD; Type 21K9))?
>
>
>
>

Re: Reason why "nocache" option is not displayed in "mount"?

[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.

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"?

[Alexander Leidinger]

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

Boot failure, amd64 (HP EliteBook 650 G10)

[Graham Perrin]

amd64.

AFAICT the EliteBook 650 G10 was introduced around May 2023.

Does anything in the three photographs tally with a report in Bugzilla?

Any overlap with 
 
for AMD Ryzen 7 CPU (Lenovo ThinkPad P16s Gen2 (AMD; Type 21K9))?