Re: [RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2?

[Alexander Leidinger via freebsd-current]

Quoting Rick Macklem  (from Tue, 4 Jan 2022  
03:18:36 +):



Konstantin Belousov wrote:
[good stuff snipped]

The v4 NFS is very different from v3, it is not an upgrade, it is rather
a different network filesystem with some (significant) similarities to v3.

That said, it should be fine changing the defaults, but you need to ensure
that reasonable scenarios, like the changed FreeBSD client mounting
from v3-only server, still work correctly.  The change should be made in a
way that only affects client that connects to the server that has both
v4 and v3.

A particular test case that needs to be done is the diskless NFS root fs.
This case must use NFSv3 and if it is not the default, it might break?
I am not really set up to test this at this time.
(There are assorted reasons that NFSv4 does not, or at least might not,
 work for a diskless root fs, but that is a separate topic.)

Other than testing diskless NFS root file systems, I do not have a
strong opinion w.r.t. whether the default should change.

If the default stays as NFSv3, a fallback to NFSv4 could be done, which
would handle the NFSv4 only server case. (No one uses NFSv2 any more,
so the fallback to NFSv2 is almost irrelevant, imho.)


As you particiate in interoperability tests, would it make sense to  
check how those other implementations handle this case? I naively  
assume you have some contacts or a mailinglist you could use for that.


Bye,
Alexander.


--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF

Re: Waiting for bufdaemon

[Alexander Leidinger via freebsd-current]

Quoting Konstantin Belousov  (from Fri, 5 Mar  
2021 22:43:58 +0200):



On Fri, Mar 05, 2021 at 04:03:11PM +0900, Yasuhiro Kimura wrote:

Dear src committers,

From: Yasuhiro Kimura 
Subject: Re: Waiting for bufdaemon
Date: Thu, 28 Jan 2021 05:02:42 +0900 (JST)

>>> I have been experiencing same problem with my 13-CURRENT amd64
>>> VirtualBox VM for about a month. The conditions that the problem
>>> happens are unclear and all what I can say is
>>>
>>> * It happens only after I login in the VM and do something for a
>>>   while. If I boot the VM and shut it down immediately, it never
>>>   happens.
>>> * When the problem happens, one or more unkillable processes seem to
>>>   be left.
>>
>> CPU of my host is not AMD but Intel. According to the
>> /var/run/dmesg.boot of VM, information of CPU is as following.
>>
>> CPU: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz (3000.09-MHz K8-class CPU)
>>   Origin="GenuineIntel"  Id=0x906ed  Family=0x6  Model=0x9e  Stepping=13
>>
Features=0x1783fbff
>>
Features2=0x5eda2203

>>   AMD Features=0x28100800
>>   AMD Features2=0x121
>>   Structured Extended  
Features=0x842421

>>   Structured Extended Features3=0x3400
>>   IA32_ARCH_CAPS=0x29
>>   TSC: P-state invariant
>>
>> Just FYI.
>
> It took for a while to investigate, but according to the result of
> bisect following commit is the source of problem in my case.
>
> --
> commit 84eaf2ccc6a
> Author: Konstantin Belousov 
> Date:   Mon Dec 21 19:02:31 2020 +0200
>
> x86: stop punishing VMs with low priority for TSC timecounter
>
> I suspect that virtualization techniques improved from the  
time when we
> have to effectively disable TSC use in VM.  For instance, it  
was reported

> (complained) in https://github.com/JuliaLang/julia/issues/38877 that
> FreeBSD is groundlessly slow on AWS with some loads.
>
> Remove the check and start watching for complaints.
>
> Reviewed by:emaste, grehan
> Discussed with: cperciva
> Sponsored by:   The FreeBSD Foundation
> Differential Revision:  https://reviews.freebsd.org/D27629
> --
>
> I confirmed the problem still happens with 5c325977b11 but reverting
> above commit fixes it.

Would someone please revert above commit from main, stable/13 and
releng/13.0? As I wrote previous mail I submitted this problem to
Bugzilla as bug 253087 and added the committer to Cc. But there is no
response for 34 days.

I confirmed the problem still happens with 37cd6c20dbc of main and
13.0-RC1.


My belief is that this commit helps more users than it hurts.  Namely,
the VMWare and KVM users, which are majority, use fast timecounter,
comparing to the more niche hypervisors like VirtualBox.

For you, a simple but manual workaround, setting the timecounter to
ACPI (?) or might be HPET, with a loader tunable, should do it.


Do you propose this to him as a test if this solves the issue with the  
intend to change the code to use a more suitable TC if VirtualBox is  
detected?


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpZtn2nb4T4U.pgp
Description: Digitale PGP-Signatur