Miroslav Lachman wrote:
[good stuff snipped]
> Apple sources can be found there
> https://opensource.apple.com/source/smb/ with all the history from SMBv1
> to SMBv3. The files have original copyright header from 2001 Boris Popov
> (same as FreeBSD) but otherwise it is very different code due to
>
I am going to look at the OpenSolaris code, to see if
I think it will be an easier port.
rick
From: Miroslav Lachman <000.f...@quip.cz>
Sent: Monday, November 1, 2021 5:47 PM
To: Rick Macklem; freebsd-curr...@freebsd.org; freebsd-stable
Cc: Yuri
Sub
rick
From: Miroslav Lachman <000.f...@quip.cz>
Sent: Monday, January 10, 2022 10:27 AM
To: Rick Macklem; freebsd-curr...@freebsd.org; freebsd-stable
Cc: Yuri
Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14
CAUTION: This email originated from outside of the Un
Yuri wrote:
> Rick Macklem wrote:
> > I have downloaded the final version of the opensolaris
> > smbfs and it looks much more reasonable to port to
> > FreeBSD.
>
> What do you mean by "final version of the opensolaris smbfs", the one
> from 2010? Pleas
Mark Saad wrote:
[stuff snipped]
> So I am looking at the Apple and Solaris code, provided by rick. I am not
> sure if the illumos code provides SMB2 support. They based the solaris
> code on Apple SMB-217.x which is from OSX 10.4 . Which I am sure
> predates smb2 .
>
> https://github.com/apple-os
Yoshihiro Ota wrote:
> Hi,
>
> I'm on stable/13 with latest code base.
> I started testing pre-13.1 branch.
>
> I noticed major performance degrades with NFS when all CPUs are fully
> utilized.
>
> This happends with stable/13 but not releng/13.0 nor releng/12.3.
NFS performance is sensitive to R
mike tancsa wrote:
> On 3/20/2022 7:43 AM, mike tancsa wrote:
>> On 3/18/2022 9:18 PM, Yoshihiro Ota wrote:
>>> I had built several versions between releng/13.0 branch point to
>>> stable/13 (before releng/13.1 was created) and all of them had such
>> performance degrade.
>>>
>>> I started suspect
into it.
rick
I added "enable DDB" to i386 kernel but didn't touch amd64 kernel.
Both amd64 and i386 looks okay with releng/13.1.
Hiro
On Sun, 20 Mar 2022 20:45:30 +
Rick Macklem wrote:
> mike tancsa wrote:
> > On 3/20/2022 7:43 AM, mike tancsa wrote:
> >>
Alan Somers wrote:
> I have a FreeBSD 13 (tested on both 13.0-RELEASE and 13.1-RC5) desktop
> mounting /usr/home over NFS 4.2 from an 13.0-RELEASE server. It
> worked fine until a few weeks ago. Now, the desktop's performance
> slowly degrades. It becomes less and less responsive until I restar
Alan Somers wrote:
> On Wed, May 4, 2022 at 5:23 PM Rick Macklem wrote:
> >
> > Alan Somers wrote:
> > > I have a FreeBSD 13 (tested on both 13.0-RELEASE and 13.1-RC5) desktop
> > > mounting /usr/home over NFS 4.2 from an 13.0-RELEASE server. It
> > &g
Alan Somers wrote:
> On Wed, May 4, 2022 at 6:56 PM Rick Macklem wrote:
> >
> > Alan Somers wrote:
> > > On Wed, May 4, 2022 at 5:23 PM Rick Macklem wrote:
> > > >
> > > > Alan Somers wrote:
> > > > > I have a FreeBSD 13 (teste
Alan Somers wrote:
> On Thu, May 5, 2022 at 8:49 AM Rick Macklem wrote:
> >
> > Alan Somers wrote:
> > > On Wed, May 4, 2022 at 6:56 PM Rick Macklem wrote:
> > > >
> > > > Alan Somers wrote:
> > > > > On Wed, May 4, 2022 at 5:23
Peter wrote:
> Hija,
> I have a problem with NFSv4:
>
> The configuration:
> Server Rel. 13.1-RC2
> nfs_server_enable="YES"
> nfs_server_flags="-u -t --minthreads 2 --maxthreads 20 -h ..."
Allowing it to go down to 2 threads is very low. I've never even
tried to run a server with less t
Peter wrote:
> Hija,
> I have a problem with NFSv4:
>
> The configuration:
> Server Rel. 13.1-RC2
> nfs_server_enable="YES"
> nfs_server_flags="-u -t --minthreads 2 --maxthreads 20 -h ..."
> mountd_enable="YES"
> mountd_flags="-S -p 803 -h ..."
> rpc_lockd_enable="YES"
>
Ganbold Tsagaankhuu wrote:
> Hi,
>
> We are having trouble with NFS running on STABLE:
>
> Aug 26 02:21:42 iron2 kernel: newnfs_request: Wrong session srvslot=1 slot=0
> Aug 26 02:21:42 iron2 kernel: freeing free slot!!
> Aug 26 02:21:43 iron2 kernel: newnfs_request: Wrong session srvslot=1 slot
Ganbold Tsagaankhuu wrote:
> Rick,
>
> On Fri, Aug 26, 2022 at 11:18 AM Rick Macklem >
> >mailto:rmack...@uoguelph.ca>> wrote:
Ganbold Tsagaankhuu mailto:ganb...@gmail.com>> wrote:
> > Hi,
> >
> > We are having trouble with NFS running
Ganbold Tsagaankhuu wrote:
> > Rick,
> >
> > On Fri, Aug 26, 2022 at 11:18 AM Rick Macklem >
> > >mailto:rmack...@uoguelph.ca>> wrote:
Ganbold Tsagaankhuu mailto:ganb...@gmail.com>> wrote:
> > > Hi,
> > >
> > > We are having
Ronald Klop wrote:
>On 8/27/22 00:17, Rick Macklem wrote:
>> Ganbold Tsagaankhuu wrote:
>>>> Rick,
>>>>
>>>> On Fri, Aug 26, 2022 at 11:18 AM Rick Macklem >
>>>> >mailto:rmack...@uoguelph.ca>> wrote:
>> Ganbold Tsagaa
Ronald Klop wrote:
> Van: Pete French
> Datum: 28 augustus 2022 10:16
> Aan: stable@freebsd.org
> Onderwerp: Re: double used hostuuids - Re: NFS issue - newnfs_request: Wrong
> session srvslot=1 slot=0, freeing free slot!!
>
> On 27/08/2022 16:18, Rick Macklem wrote:
&
Also, if you have multiple clients, make sure that they
all have unique /etc/hostid's. A duplicate machine with
the same /etc/hostid as another one will screw up NFSv4
really badly.
rick
From: owner-freebsd-sta...@freebsd.org on
behalf of Peter
Sent: Sa
On Thu, Mar 16, 2023 at 1:44 PM Attila Nagy wrote:
>
> Hi,
>
> As this is super annoying, I'm willing to pay a $500 bounty for solving this
> issue (whomever is first, however I don't anticipate a big competition :)
> Having an invoice would be best, but I'm willing to accept individuals as
> w
Oops, an MFC I did to-day broke the build for
stable/13. I have reverted the commits, so I
think things should be ok now.
My mistake was to assume that a change in
a .h file within a #ifdef _KERNEL would not
affect a userland build. (It turns out that code
in libprocstat defines _KERNEL.)
I'll wo
I am reposting this to the mailing list, as permitted
by Terry Kennedy, since others might be able to
provide useful input and the discussion gets archived.
rick
On Fri, May 26, 2023 at 4:34 PM Terry Kennedy wrote:
>
> On 2023-05-26 18:47, Rick Macklem wrote:
> > Btw, in general it
On Sun, May 28, 2023 at 5:27 PM Terry Kennedy wrote:
>
> > I have gathered the data requested and I'm attaching it to
> > this message instead of inlining it, so only those people who
> > want to look at it will see it.
>
>So much for that idea... I was expecting the former mailman
> behavio
Since the reply ended up at the end of the long email, I'll
post it here as well.
On Sun, May 28, 2023 at 5:55 PM Terry Kennedy wrote:
>
>[This is the first time I'm trying to use the new FreeBSD
> list serer, and it is behaving really bizarrely - it stripped
> out the attachment in my first
On Thu, Aug 31, 2023 at 12:05 PM Garrett Wollman wrote:
>
> < said:
>
> > Any suggestions on what we should monitor or try to adjust?
I remember you mentioning that you tried increasing kern.maxvnodes
but I was wondering if you've tried bumping it way up (like 10X what it
currently is)?
You coul
On Fri, Nov 17, 2023 at 7:10 PM Garrett Wollman wrote:
>
> < said:
>
> > Looks like main still has this problem. I exported a ZFS file system from
> > a 15-current system to the same 13.2 client, and it exhibits the problem
> > (EIO from NFSv3). So the problem is most likely in 14.0 as well.
>
>
Pointy hat goes on me.
This should be fixed now, rick
On Wed, Jan 3, 2024 at 5:56 AM Helge Oldach wrote:
>
> Hi Mike,
>
> mike tancsa wrote on Wed, 03 Jan 2024 14:47:31 +0100 (CET):
> > Hi,
> >
> > Both my i386 and amd64 kernels wont build this AM. It seems to be
> > due to
> >
> > https://
On Sat, Jan 20, 2024 at 6:48 AM Marek Zarychta
wrote:
>
> Dear List,
>
> there were some efforts to allow running nfsd(8) inside the jail, but is
> mounting an NFS share from the jail allowed? Inside the jail
> "security.jail.mount_allowed" is set to 1, I also added "add path net
> unhide" to the
On Sat, Jan 20, 2024 at 10:55 AM Charles Sprickman wrote:
>
>
>
> > On Jan 20, 2024, at 10:09 AM, Rick Macklem wrote:
> >
> > On Sat, Jan 20, 2024 at 6:48 AM Marek Zarychta
> > wrote:
> >>
> >> Dear List,
> >>
> >> the
On Tue, Feb 27, 2024 at 9:30 PM Garrett Wollman wrote:
>
> Hi, all,
>
> We've had some complaints of NFS hanging at unpredictable intervals.
> Our NFS servers are running a 13-stable from last December, and
> tonight I sat in front of the monitor watching `nfsstat -dW`. I was
> able to clearly se
On Tue, Feb 27, 2024 at 9:30 PM Garrett Wollman wrote:
>
> Hi, all,
>
> We've had some complaints of NFS hanging at unpredictable intervals.
> Our NFS servers are running a 13-stable from last December, and
> tonight I sat in front of the monitor watching `nfsstat -dW`. I was
> able to clearly se
On Wed, Feb 28, 2024 at 4:04 PM Rick Macklem wrote:
>
> On Tue, Feb 27, 2024 at 9:30 PM Garrett Wollman
> wrote:
> >
> > Hi, all,
> >
> > We've had some complaints of NFS hanging at unpredictable intervals.
> > Our NFS servers are running a 13-stable
a thought in the morning
>
> Regards,
> Ronald.
>
> Van: Rick Macklem
> Datum: 1 maart 2024 00:31
> Aan: Garrett Wollman
> CC: stable@freebsd.org, rmack...@freebsd.org
> Onderwerp: Re: 13-stable NFS server hang
>
> On Wed, Feb 28, 2024 at 4:04PM Rick Mackle
ls to
> ith...@uoguelph.ca.
>
>
> On Fri, Mar 01, 2024 at 06:23:56AM -0800, Rick Macklem wrote:
> > On Fri, Mar 1, 2024 at 12:00 AM Ronald Klop wrote:
> > >
> > > Interesting read.
> > >
> > > Would it be possible to separate locking for admin ac
ls to
> ith...@uoguelph.ca.
>
>
> On Sat, Mar 02, 2024 at 05:40:08AM -0800, Rick Macklem wrote:
> > On Fri, Mar 1, 2024 at 10:51 PM Konstantin Belousov
> > wrote:
> > >
> > > CAUTION: This email originated from outside of the University of Guelph.
> > &
On Sat, Mar 2, 2024 at 9:25 PM Garrett Wollman wrote:
>
> <
> > I believe this explains why vn_copy_file_range sometimes takes much
> > longer than a second: our servers often have lots of data waiting to
> > be written to disk, and if the file being copied was recently modified
> > (and so is dir
On Sat, Mar 2, 2024 at 8:28 PM Garrett Wollman wrote:
>
>
> I wrote previously:
> > PIDTID COMMTDNAME KSTACK
> > 997 108481 nfsdnfsd: mastermi_switch
> > sleepq_timedwait _sleep nfsv4_lock nfsrvd_dorpc nfssvc_program
> > svc_run_internal s
On Sun, Mar 3, 2024 at 1:17 PM Rick Macklem wrote:
>
> On Sat, Mar 2, 2024 at 8:28 PM Garrett Wollman wrote:
> >
> >
> > I wrote previously:
> > > PIDTID COMMTDNAME KSTACK
> > > 997 108481 nfsdnfsd: maste
On Sun, Mar 3, 2024 at 3:27 PM Rick Macklem wrote:
>
> On Sun, Mar 3, 2024 at 1:17 PM Rick Macklem wrote:
> >
> > On Sat, Mar 2, 2024 at 8:28 PM Garrett Wollman
> > wrote:
> > >
> > >
> > > I wrote previously:
> > > > PIDTID CO
On Sun, Mar 3, 2024 at 4:28 PM Rick Macklem wrote:
>
> On Sun, Mar 3, 2024 at 3:27 PM Rick Macklem wrote:
> >
> > On Sun, Mar 3, 2024 at 1:17 PM Rick Macklem wrote:
> > >
> > > On Sat, Mar 2, 2024 at 8:28 PM Garrett Wollman
> > > wrot
On Tue, Mar 5, 2024 at 2:13 AM Ronald Klop wrote:
>
>
> Van: Rick Macklem
> Datum: vrijdag, 1 maart 2024 15:23
> Aan: Ronald Klop
> CC: Garrett Wollman , stable@freebsd.org,
> rmack...@freebsd.org
> Onderwerp: Re: 13-stable NFS server hang
>
> On Fri, Mar 1, 2024
On Tue, Mar 5, 2024 at 6:34 AM Rick Macklem wrote:
>
> On Tue, Mar 5, 2024 at 2:13 AM Ronald Klop wrote:
> >
> >
> > Van: Rick Macklem
> > Datum: vrijdag, 1 maart 2024 15:23
> > Aan: Ronald Klop
> > CC: Garrett Wollman , stable@freebsd.org,
>
On Wed, Mar 6, 2024 at 3:46 AM Ronald Klop wrote:
>
>
> Van: Rick Macklem
> Datum: dinsdag, 5 maart 2024 15:43
> Aan: Ronald Klop
> CC: rmack...@freebsd.org, Garrett Wollman ,
> stable@freebsd.org
> Onderwerp: Re: 13-stable NFS server hang
>
> On Tue, Mar 5, 2024
On Thu, Mar 7, 2024 at 7:59 PM Garrett Wollman wrote:
>
> <
> > I believe this explains why vn_copy_file_range sometimes takes much
> > longer than a second: our servers often have lots of data waiting to
> > be written to disk, and if the file being copied was recently modified
> > (and so is dir
Hi,
I boned up and, when wireshark reported that a NFSv4
packet was incorrectly constructed, I changed the NFSv4
code the "fix" the problem.
I found out recently (at a IETF NFSv4 testing event) that
wireshark was buggy and the code was actually broken
by the "fix".
I have now corrected this in m
On Thu, Jun 27, 2024 at 7:52 AM void wrote:
>
> After upgrading, I noticed messages like these appearing during
> rebooting, immediately after kernel: NFS access cache time=60
>
> kernel: rpc.umntall: 10.1.1.102: MOUNTPROG: RPC: Port mapper failure - RPC:
> Timed out
>
> sometimes it appears twic
On Fri, Jun 28, 2024 at 5:23 AM void wrote:
>
> Hi Rick,
>
> On Thu, Jun 27, 2024 at 09:29:51AM -0700, Rick Macklem wrote:
>
> >rpcbind_enable="YES"
> >nfs_client_enable="YES"
> >
> >If you have at least one of these in your /etc/rc.conf,
On Sat, Jun 29, 2024 at 3:18 AM void wrote:
>
> On Fri, Jun 28, 2024 at 01:23:29PM +0100, void wrote:
>
> (snip)
>
> Just to add to this, the reported error does *not* occur on
> 15.0-CURRENT #5 n270917-5dbf886104b4 arm64
>
> and that system has *only* nfs_client_enable="YES"
>
> and it's a slower
On Thu, Jul 11, 2024 at 4:47 AM void wrote:
>
> Hi Rick,
>
>
> >>
> >> The nfs server is 14-stable and the exported dir is zfs with the sharenfs
> >> property set.
> >> The client (14.1-p1) is a VM on a different machine but the same network.
> >>
> >> I'll try putting rpcbind_enable=YES in /etc/
On Sat, Jul 13, 2024 at 7:02 PM Garrett Wollman wrote:
>
> I'm migrating an old file server to new hardware using syncoid. Every
> so often, the `zfs send` process gets stuck with the following
> kstacks:
>
> 7960 108449 zfs - mi_switch
> sleepq_catch_signals s
On Sat, Jul 13, 2024 at 8:19 PM Garrett Wollman wrote:
>
> <
> said:
>
> > # ps axHl
> > should show you what wchan's the processes are waiting on and that might
> > give you a clue w.r.t. what is happening?
>
> zfs is waiting to write into the pipe and pv (the progress meter) is
> waiting in sel
On Sat, Jul 13, 2024 at 8:50 PM Rick Macklem wrote:
>
> On Sat, Jul 13, 2024 at 8:19 PM Garrett Wollman
> wrote:
> >
> > <
> > said:
> >
> > > # ps axHl
> > > should show you what wchan's the processes are waiting on and that might
>
On Sun, Jul 14, 2024 at 10:32 AM Garrett Wollman
wrote:
> <
> said:
>
> > Just to clarify it, are you saying zfs is sleeping on "pipewr"?
> > (There is also a msleep() for "pipbww" in pipe_write().)
>
> It is sleeping on pipewr, yes.
>
> [wollman@nfs-prod-11 ~]$ sysctl kern.ipc.pipekva
> kern.ipc
olce@ reported an issue where the credentials used for mapped
user exports (for the NFS server) could have cr_ngroups == 0.
At first I thought this was a mountd bug, but he pointed out the
exports(5) manpage, which says:
Note that user: should be used to distinguish a credential containing
no grou
he email, from what I've seen.)
Good luck with it, rick
>
> On Thu, Nov 21, 2024 at 6:35 PM Rick Macklem wrote:
>>
>> On Thu, Nov 21, 2024 at 1:22 PM Zaphod Beeblebrox wrote:
>> >
>> >
>> > I've tried a lot of different combinations of r
On Wed, Nov 20, 2024 at 8:01 PM Michael Proto wrote:
>
> Hello all,
>
> Running into an issue with a 14.1 server that I think is a bug, though
> it may be me not interpreting documentation correctly so I wanted to
> ask here.
=alldirs simply means that any directory within the server file system
c
On Mon, Nov 25, 2024 at 3:57 PM Rick Macklem wrote:
>
> On Mon, Nov 25, 2024 at 2:55 PM Rick Macklem wrote:
> >
> > On Wed, Nov 20, 2024 at 8:01 PM Michael Proto wrote:
> > >
> > > Hello all,
> > >
> > > Running into an issue with a 14.1 s
On Sun, Nov 24, 2024 at 2:17 PM Rick Macklem wrote:
>
> On Thu, Nov 21, 2024 at 9:16 PM Zaphod Beeblebrox wrote:
> >
> > lo0 has 127.0.0.1, ::1 (both first in their lists). It also has a pile of
> > other IPs that are used by jails. This has not changed
> I just d
On Mon, Nov 25, 2024 at 2:55 PM Rick Macklem wrote:
>
> On Wed, Nov 20, 2024 at 8:01 PM Michael Proto wrote:
> >
> > Hello all,
> >
> > Running into an issue with a 14.1 server that I think is a bug, though
> > it may be me not interpreting documentation c
On Wed, Nov 20, 2024 at 8:01 PM Michael Proto wrote:
>
> Hello all,
>
> Running into an issue with a 14.1 server that I think is a bug, though
> it may be me not interpreting documentation correctly so I wanted to
> ask here.
>
> Using NFSv3, with FreeBSD 14.1 as the NFS server. Based on what I se
On Thu, Nov 21, 2024 at 1:22 PM Zaphod Beeblebrox wrote:
>
>
> I've tried a lot of different combinations of rc variables. On 13.3 and
> 14.1, nfsd in most (non-v4-only) configurations registers to rpcbind as
> expected. This is true of restarting nfsd and using nfsd -r.
>
> However on 14.2, I
On Thu, Nov 21, 2024 at 1:56 PM Michael Proto wrote:
>
> On Thu, Nov 21, 2024 at 7:11 AM Rick Macklem wrote:
> >
> > On Wed, Nov 20, 2024 at 8:01 PM Michael Proto wrote:
> > >
> > > Hello all,
> > >
> > > Running into an issue with a 14.1 s
63 matches
Mail list logo
