On Thu, Apr 25, 2024 at 8:51 PM Rick Macklem wrote:
>
> On Thu, Apr 25, 2024 at 8:09 PM Konstantin Belousov wrote:
> >
> > On Thu, Apr 25, 2024 at 07:49:23PM -0700, Rick Macklem wrote:
> > > Hi,
> > >
> > > This week I have been doing active testing a
On Thu, Apr 25, 2024 at 8:09 PM Konstantin Belousov wrote:
>
> On Thu, Apr 25, 2024 at 07:49:23PM -0700, Rick Macklem wrote:
> > Hi,
> >
> > This week I have been doing active testing as a part of an IETF
> > bakeathon for NFSv4. During the week I had a NFSv4 cl
Hi,
This week I have been doing active testing as a part of an IETF
bakeathon for NFSv4. During the week I had a NFSv4 client
crash. On the surface, it is straightforward, in that it called
ncl_doio_directwrite() and the field called b_caller1 was NULL.
Now, here's the weird part...
On Tue, Apr 9, 2024 at 8:04 AM Rick Macklem wrote:
>
> On Tue, Apr 9, 2024 at 7:46 AM Rick Macklem wrote:
> >
> > On Tue, Apr 9, 2024 at 4:47 AM David Wolfskill wrote:
> > >
> > > Machine had been running:
> > >
> > > FreeBSD 15.0-CURR
On Tue, Apr 9, 2024 at 7:46 AM Rick Macklem wrote:
>
> On Tue, Apr 9, 2024 at 4:47 AM David Wolfskill wrote:
> >
> > Machine had been running:
> >
> > FreeBSD 15.0-CURRENT #43 main-n269202-4e7aa03b7076: Mon Apr 8 11:19:58 UTC
> > 2024
> > r...@f
On Tue, Apr 9, 2024 at 4:47 AM David Wolfskill wrote:
>
> Machine had been running:
>
> FreeBSD 15.0-CURRENT #43 main-n269202-4e7aa03b7076: Mon Apr 8 11:19:58 UTC
> 2024
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64 1500018 1500018
>
> This was an
Hi,
I have a hunch that no one uses the WebNFS stuff, which is done via exports(5)
using the -public or -webnfs exports options.
I would like to deprecate these exports options, but thought I'd ask
in case anyone
uses them?
rick
Shouldn't be a problem. The socket used for lookup is
AF_UNIX (uses unp_connectat) and the NFS socket
will always be UDP or TCP.
Different sockets imply different socket locks.
At least that's my interpretation, rick
On Wed, Apr 3, 2024 at 11:33 AM Bjoern A. Zeeb
wrote:
>
>
> NFS root boot of
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
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
On Wed, Mar 6, 2024 at 10:56 AM Matthew L. Dailey
wrote:
>
> Posting a few updates on this issue.
>
> I was able to induce a panic on a CURRENT kernel (20240215), built with
> GENERIC-KASAN and running kern.kstack_pages=6 (default) after ~189
> hours. The panic message and backtrace are below -
On Tue, Feb 20, 2024 at 11:21 AM Matthew L. Dailey
wrote:
>
> Hi all,
>
> I induced a panic on my CURRENT (20240215-d79b6b8ec267-268300) VM after
> about 24 hours. This is the one without any debugging, so it only
> confirms the fact that the panics we've been experiencing still exist in
>
On Mon, Feb 19, 2024 at 7:44 AM Matthew L. Dailey
wrote:
>
> Hi all,
>
> So I finally induced a panic on a "pure" ufs system - root and exported
> filesystem were both ufs. So, I think this definitively rules out zfs as
> a source of the issue.
>
> This panic was on 14.0p5 without debugging
On Fri, Feb 9, 2024 at 10:23 AM Matthew L. Dailey
wrote:
>
> I had my first kernel panic with a KASAN kernel after only 01:27. This
> first panic was a "double fault," which isn't anything we've seen
> previously - usually we've seen trap 9 or trap 12, but sometimes others.
> Based on the
On Fri, Feb 9, 2024 at 2:04 PM Zaphod Beeblebrox wrote:
>
> Just in case it's relevant, I'm carrying around this patch on my fairly busy
> little RISC-V machine.
>
> diff --git a/sys/fs/nfsclient/nfs_clvnops.c b/sys/fs/nfsclient/nfs_clvnops.c
> index 0b8c587a542c..85c0ebd7a10f 100644
> ---
On Tue, Jan 30, 2024 at 2:57 PM Mike Karels wrote:
>
> On 30 Jan 2024, at 15:48, Cy Schubert wrote:
>
> > In message > om>
> > , Rick Macklem writes:
> >> On Tue, Jan 30, 2024 at 10:49=E2=80=AFAM Mike Karels
> >> wrot=
> >> e:
>
On Tue, Jan 30, 2024 at 10:49 AM Mike Karels wrote:
>
> On 30 Jan 2024, at 3:00, Olivier Certner wrote:
>
> > Hi Warner,
> >
> >> I strongly oppose this notion to control this from loader.conf. Root is
> >> mounted read-only, so it doesn't matter. That's why I liked Mike's
> >> suggestion: root
autofs_readdir+0x2ce
> > > #11 0x809f8ae0 at VOP_READDIR_APV+0x20
> > > #12 0x806c3002 at kern_getdirentries+0x222
> > > #13 0x806c33a9 at sys_getdirentries+0x29
> > > #14 0x809d6180 at amd64_syscall+0x110
> > > #15 0x
_readdir+0x1f0
> #8 0x8069c61a at vop_sigdefer+0x2a
> #9 0x809f8ae0 at VOP_READDIR_APV+0x20
> #10 0x81ce75de at autofs_readdir+0x2ce
> #11 0x809f8ae0 at VOP_READDIR_APV+0x20
> #12 0x806c3002 at kern_getdirentries+0x222
> #13 0x806c33a9 at sys_getd
On Sat, Jan 13, 2024 at 12:39 PM Ronald Klop wrote:
>
>
> Van: FreeBSD User
> Datum: 13 januari 2024 19:34
> Aan: FreeBSD CURRENT
> Onderwerp: NFSv4 crash of CURRENT
>
> Hello,
>
> running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e82a:
> Sat Jan 13 18:08:32
> CET 2024
On Wed, Jan 10, 2024 at 12:44 PM Lyndon Nerenberg (VE7TFX/VE6BBM)
wrote:
>
> Olivier Certner writes:
>
> > I've never found any compelling reason in most uses to enable "atime",
> > except
> > perhaps local mail but as addressed in other answers it is a relic of the
> > pa
> > st mostly
Oh, and thanks to everyone who put up with my lame
ZFS snapshot questions.
rick
On Thu, Nov 23, 2023 at 8:13 AM Rick Macklem wrote:
>
> On Sat, Nov 18, 2023 at 8:10 PM Mike Karels wrote:
> >
> > On 18 Nov 2023, at 21:19, Rick Macklem wrote:
> >
> > > On Sat, No
On Sat, Nov 18, 2023 at 8:10 PM Mike Karels wrote:
>
> On 18 Nov 2023, at 21:19, Rick Macklem wrote:
>
> > On Sat, Nov 18, 2023 at 4:43 PM Mike Karels wrote:
> >>
> >> On 18 Nov 2023, at 17:23, Rick Macklem wrote:
> >>
> >>> On Sat, Nov 18, 2
Thanks, I've gone with B, rick
On Wed, Nov 22, 2023 at 1:30 PM Warner Losh wrote:
>
>
>
> On Wed, Nov 22, 2023, 1:24 PM Rick Macklem wrote:
>>
>> Hi,
>>
>> I have a patch currently under review at D42672 that fixes visibility
>> of snapshots under .zfs/
Hi,
I have a patch currently under review at D42672 that fixes visibility
of snapshots under .zfs/snapshot for NFS clients.
It adds a new function called vfs_exjail_clone(), which the ZFS
code needs to use to fill in the mnt_exjail field.
Since the OpenZFS code is supposed to build for 12.2 or
On Sat, Nov 18, 2023 at 4:43 PM Mike Karels wrote:
>
> On 18 Nov 2023, at 17:23, Rick Macklem wrote:
>
> > On Sat, Nov 18, 2023 at 2:27 PM Mike Karels wrote:
> >>
> >> On 18 Nov 2023, at 15:58, Rick Macklem wrote:
> >>
> >>> On S
On Sat, Nov 18, 2023 at 2:27 PM Mike Karels wrote:
>
> On 18 Nov 2023, at 15:58, Rick Macklem wrote:
>
> > On Sat, Nov 18, 2023 at 8:09 AM Rick Macklem wrote:
> >>
> >> On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote:
> >>>
> >>> On 17
ls to
> ith...@uoguelph.ca.
>
>
> On 11/18/23 17:09, Rick Macklem wrote:
> > On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote:
> >>
> >> On 17 Nov 2023, at 22:14, Mike Karels wrote:
> >>
> >>> On 17 Nov 2023, at 21:24, Rick Macklem wrote:
>
On Sat, Nov 18, 2023 at 8:09 AM Rick Macklem wrote:
>
> On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote:
> >
> > On 17 Nov 2023, at 22:14, Mike Karels wrote:
> >
> > > On 17 Nov 2023, at 21:24, Rick Macklem wrote:
> > >
> > >> Most o
On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote:
>
> On 17 Nov 2023, at 22:14, Mike Karels wrote:
>
> > On 17 Nov 2023, at 21:24, Rick Macklem wrote:
> >
> >> Most of the changes in stable/13 that are not in releng/13.2
> >> are the "
On Tue, Nov 14, 2023 at 1:20 PM Konstantin Belousov wrote:
>
> On Tue, Nov 14, 2023 at 06:47:46PM +0100, Mateusz Guzik wrote:
> > On 11/14/23, Alexander Motin wrote:
> > > On 14.11.2023 12:39, Mateusz Guzik wrote:
> > >> One of the vnodes is probably not zfs, I suspect this will do it
> > >>
On Tue, Nov 14, 2023 at 1:15 PM Mateusz Guzik wrote:
>
> On 11/14/23, Rick Macklem wrote:
> > On Tue, Nov 14, 2023 at 10:46 AM Alexander Motin wrote:
> >>
> >> On 14.11.2023 12:44, Alexander Motin wrote:
> >> > On 14.11.2023 12:39, Mateusz Guzik wr
On Tue, Nov 14, 2023 at 10:46 AM Alexander Motin wrote:
>
> On 14.11.2023 12:44, Alexander Motin wrote:
> > On 14.11.2023 12:39, Mateusz Guzik wrote:
> >> One of the vnodes is probably not zfs, I suspect this will do it
> >> (untested):
> >>
> >> diff --git
On Tue, Oct 31, 2023 at 10:06 AM John Baldwin wrote:
>
> On 10/30/23 3:41 AM, Zhenlei Huang wrote:
> >
> >
> >> On Oct 30, 2023, at 12:09 PM, Zhenlei Huang wrote:
> >>
> >>
> >>
> >>> On Oct 29, 2023, at 5:43 PM, Gordon Bergling wrote:
> >>>
> >>> Hi,
> >>>
> >>> I am currently building a new
On Thu, Oct 26, 2023 at 11:28 AM Rick Macklem wrote:
>
> On Wed, Oct 25, 2023 at 8:10 PM Simon J. Gerraty wrote:
> >
> > Rick Macklem wrote:
> > > > kern.rpctls.tls.snd_msgbytes: 20828
> > > > kern.rpctls.tls.snd_msgcnt: 57
&g
On Wed, Oct 25, 2023 at 8:10 PM Simon J. Gerraty wrote:
>
> Rick Macklem wrote:
> > > kern.rpctls.tls.snd_msgbytes: 20828
> > > kern.rpctls.tls.snd_msgcnt: 57
> > > kern.rpctls.tls.rcv_tmsgbytes: 12336
> > > kern.rpctls.tls.rcv_msgcnt: 57
> >
On Wed, Oct 25, 2023 at 6:33 PM Simon J. Gerraty wrote:
>
> Freddie Cash wrote:
> > Have no technical comments, but a style suggestion: put the tls at the end
> > to make the output look nicer. :)
> >
> > kern.rpctls.snd_msgbytes: 21508
> > kern.rpctls.snd_msgbytes_tls: 20828
> >
of alert
messages (basically "Peer Resets" from what I've seen).
Thanks, rick
ps: Just replying to one of the messages and, yes, I did top post..
On Wed, Oct 25, 2023 at 8:47 AM Freddie Cash wrote:
>
> On Tue, Oct 24, 2023 at 10:56 PM Rick Macklem wrote:
>>
>> Garrett Wo
Garrett Wollman asked me via email how a server
admin could tell what usage NFS over TLS was
happening.
I admitted that there was nothing. I have come up
with a patch that generates the following:
kern.rpctls.snd_tls_msgbytes: 21508
kern.rpctls.snd_msgbytes: 20828
kern.rpctls.snd_tls_msgcnt: 57
Hi,
I have a patch for a bug identified at last week's testing event, where
the FreeBSD NFSv4.1/4.2 client needs to rDNS a DS's address to a
FQDN so that it can generate a server principal for Kerberos.
(The bug only affects the case of a sec=krb5[ip],pnfs mount, so most
will never see it.)
On Wed, Aug 2, 2023 at 6:14 PM Konstantin Belousov wrote:
>
> On Tue, Aug 01, 2023 at 04:33:16PM -0700, Rick Macklem wrote:
> > On Mon, Jul 31, 2023 at 11:33 PM David Chisnall
> > wrote:
> > >
> > > Hi,
> > >
> > > This bit of the C s
e,
neither volatile nor
_Atomic() are used for the variable's declaration.
3 - Is there any need for other atomic_XXX() calls where the variable is used
outside of the signal handler?
In general, it is looking like FreeBSD needs to have a standard way of dealing
with this and there wil
Hi,
I just put D41265 up on phabricator. It is a trivial
change to mountd.c that defines the variable set
by got_sighup() (the SIGHUP handler) as
static volatile sig_atomic_t
instead of
static int
I did list a couple of reviewers, but if you are familiar
with this C requirement, please
Hi,
So I did an MFC that broke the stable/13 build (it's reverted now).
I didn't realize that changes inside _KERNEL in mount.h would do
this, but now I know.
Since it is only an issue for stable/13 (and not main), I'd like to do a
minimal fix on the MFC and not mess with adding #includes to
Hi,
Since there seemed to be interest in it, I have MFC'd most of
the changes needed to run nfsd(8) in a vnet jail to stable/13.
However, there is one change that *might* affect the VFS KAPI.
I need to add a pointer called mnt_exjail to struct mount.
There is a field called mnt_pad0. It is
So, the subject line basically says it.
I do a git cherry-pick to MFC. It works, but the resultant file(s) are not
correct. What do I do to fix this?
(If the merge fails, then it's easy, but there doesn't seem to be an option
on cherry-pick that forces it into "merge failed", so you can edit/add
On Mon, Apr 17, 2023 at 4:29 PM Cy Schubert wrote:
>
> In message , Pawel Jakub
> Dawi
> dek writes:
> > On 4/18/23 05:14, Mateusz Guzik wrote:
> > > On 4/17/23, Pawel Jakub Dawidek wrote:
> > >> Correct me if I'm wrong, but from my understanding there were zero
> > >> problems with block
On Tue, Mar 14, 2023 at 11:53 AM Pete Wright wrote:
>
> On Mon, Mar 13, 2023 at 07:25:07PM -0700, Rick Macklem wrote:
> > Hi,
> >
> > I have implemented a new mount option for NFSv4.1/4.2 mounts
> > that I hope will encourage use of Kerberos and TLS to help
> &g
Hi,
I have implemented a new mount option for NFSv4.1/4.2 mounts
that I hope will encourage use of Kerberos and TLS to help
secure NFS mounts. Although I do not know why users choose
to not use Kerberized NFS mounts, I think that the administrative
issues related to the "machine credential" is a
Hi,
I have just completed the kernel commits to main
needed to run the NFS server subsystem in a vnet prison.
The patch for the /etc/rc.d scripts to support the above
is in phabricator as D38809.
If anyone would like to review this, please feel free to do so.
Thanks, rick
ps: After the rc.d
Commit ed03776ca7f4 enabled the NFSD_VNET, KRPC_VNET
and KGSS_VNET macros. Kernels built with "options VIMAGE"
now have a bunch of global variables used by the NFS server
vnet'd.
It is not quite ready to run the NFS server in a vnet prison.
There are still a couple of patches in D37741 and D38371
On Thu, Feb 16, 2023 at 12:15 AM Gordon Bergling wrote:
>
> Hi,
>
> I recently tried to load ktls_ocf.ko as stated in ktls(4), but on a very
> recent -CURRENT there is no such kernel module present.
>
> Has there anything changed in -CURRENT about this kernel module?
I don't think the module
Hi,
Commit 7344856e3a6d was a large patch that added macros
that will front end the vnet macros. These macros are null ops now,
so they should not affect semantics.
However, the code did change how things get initialized for the nfsd
and that has already caused some breakage, that I think is now
PR#269328 reports an issue related to fspacectl() being
mixed with mmap'd I/O.
When working on a fix for this for the NFS client, I realized that
"man fspacectl" does not clarify if the deallocation should commit
changes to stable storage before returning success.
vop_stddeallocate() currently
I think this was fixed by a commit yesterday.
rick
On Mon, Jan 30, 2023 at 6:51 AM qroxana wrote:
>
> /etc/rc failed to run "mount -uw /" when booting from NFS root,
> this happened after the commit 906c312bbf7493ccbcce883936d67e5c66a9c3c2,
> the previous commit works fine.
>
> + mount -uw /
>
ure the doc folks would appreciate it.
>
>
> On 12/27/2022 6:34 pm, Rick Macklem wrote:
>
> Hi,
>
> I just set up a KDC, which is easy once you realize
> that Sec. 14.5 of the FreeBSD handbook is out of date.
> (I was a dummy and spent several hours installing stuff
&
Hi,
I just set up a KDC, which is easy once you realize
that Sec. 14.5 of the FreeBSD handbook is out of date.
(I was a dummy and spent several hours installing stuff
from ports before I realized it was all in the system,
but the startup file in /etc/rc.d is called "kdc" and
not "kerberos".)
On Mon, Dec 19, 2022 at 9:36 AM Bjoern A. Zeeb wrote:
> On Mon, 19 Dec 2022, Rick Macklem wrote:
> [good stuff snipped]
> > Unfortunately, this does not deal with vnet'ng the kgssapi, rpcsec_gss
> for
> > Kerberized mounts or vnet'ng NFS-over-TLS, but those could be handl
Hi,
Kostik expressed some concern w.r.t. using a non-default VNET_NFSD kernel
build option and I understand his concern, given that many prefer to use
a GENERIC kernel and binary updates.
Right now there are 29 NFS variables VNET_DEFINED() and several of them
are arrays currently sized at 500.
n/vfs_syscalls.c?r1=22520=22521=99264;
>
> [3]
>
> https://cgit.freebsd.org/src/commit/sys/kern/vfs_mount.c?id=2b4edb69f1ef62fc38b02ac22b0a3ac09e43fa77
>
>
> On Tue, 13 Dec 2022 14:19:39 -0800
> Rick Macklem wrote:
>
> > Hi,
> >
> > While working on get
On Wed, Dec 14, 2022 at 2:04 PM Rick Macklem wrote:
>
>
> On Wed, Dec 14, 2022 at 9:15 AM Tomoaki AOKI
> wrote:
>
>> Tracking the commits, it was originally introduced to
>> sys/kern/vfs_syscalls.c at r22521 [1][2] (Mon Feb 10 02:22:35 1997 by
>> dyson, submitt
scalls.c?revision=22521=markup=99264
>
> [2]
>
> https://svnweb.freebsd.org/base/head/sys/kern/vfs_syscalls.c?r1=22520=22521=99264;
>
> [3]
>
> https://cgit.freebsd.org/src/commit/sys/kern/vfs_mount.c?id=2b4edb69f1ef62fc38b02ac22b0a3ac09e43fa77
>
>
> On Tue, 13 Dec 2022 14:19:39 -08
Hi,
While working on getting mountd/nfsd to run in a vnet
prison, I came across the following lines near the
beginning of vfs_domount() in sys/kern/vfs_mount.c:
if (fsflags & MNT_EXPORTED) {
error = priv_check(td, PRIV_VFS_MOUNT_EXPORTED);
if (error)
return (error);
}
#1 -
I think this is worthy of third party testing now.
See https://people.freebsd.org/~rmacklem/nfsd-vnet-prison-setup.txt
I still haven't tried NFSv3 and I have not ported nfsuserd into the vnet,
but most NFSv4 setups don't need it anyhow.
Good luck with it if you test it, rick
ps: Just replied to
On Fri, Dec 2, 2022 at 2:03 AM Olivier Certner
wrote:
> Hi,
>
> > (snip)
> >
> > #2 - Require separate file systems and run mountd inside the jail(s).
> >
> > I think that allowing both alternatives would be too confusing
> > and it seems that most want mountd to run within the jail(s).
> > As
On Thu, Dec 1, 2022 at 8:23 AM Chris wrote:
> On 2022-11-29 16:21, Rick Macklem wrote:
> > On Sun, Nov 27, 2022 at 10:04 AM Peter Eriksson
> wrote:
> >
> >> Keep the global variables as defaults that apply to all nfsds and allow
> >> (at least some subset) t
On Thu, Dec 1, 2022 at 2:01 AM Milan Obuch wrote:
> On Thu, 01 Dec 2022 10:29:25 +0100
> Alexander Leidinger wrote:
>
> > Quoting Alan Somers (from Tue, 29 Nov 2022
> > 17:28:10 -0700):
> >
> > > On Tue, Nov 29, 2022 at 5:21 PM Rick Macklem
> > >
On Thu, Dec 1, 2022 at 1:29 AM Alexander Leidinger
wrote:
>
> Quoting Alan Somers (from Tue, 29 Nov 2022
> 17:28:10 -0700):
>
> > On Tue, Nov 29, 2022 at 5:21 PM Rick Macklem
> wrote:
>
> >> So, what do others think of enforcing the requirement that each ja
r this?
rick
> - Peter
>
>
> On Fri, Nov 25, 2022, 4:24 PM Rick Macklem wrote:
>
>> Hi,
>>
>> bz@ has encouraged me to fiddle with the nfsd
>> so that it works in a vnet jail.
>> I have now basically done so, specifically for
>> NFSv4, si
On Fri, Nov 25, 2022 at 9:06 PM Alan Somers wrote:
>
>
> On Fri, Nov 25, 2022, 4:24 PM Rick Macklem wrote:
>
>> Hi,
>>
>> bz@ has encouraged me to fiddle with the nfsd
>> so that it works in a vnet jail.
>> I have now basically done so, specifically
Hi,
bz@ has encouraged me to fiddle with the nfsd
so that it works in a vnet jail.
I have now basically done so, specifically for
NFSv4, since NFSv3 presents various issues.
What I have not yet done is put global variables
in the vnet. This needs to be done so that the nfsd
can be run in
Christoph Moench-Tegeder wrote:
>## Rick Macklem (rmack...@uoguelph.ca):
>
>> I am hoping someone knows what DNS does in this area (the
>> working group list uses terms like umlaut, which I have never
>> even heard of;-).
>
>The dry start on that topic is RFC5890
>
Hi,
Recently there has been discussion on the NFSv4 IETF working
group email list w.r.t. internationalization for the domain name
it uses for users/groups.
Right now, I am pretty sure the FreeBSD nfsuserd(8) only works
for ascii domain names, but...
I am hoping someone knows what DNS does in
On 08/18/2022 9:49 am, Larry Rosenman wrote:
> I didn't get all my mail on my bacula backups today (they backup to
> NFS mounted TrueNAS).
> Also a df hangs.
>
> Here are procstat -kk's for all:
> ler in borg in ~ via C v14.0.5-clang on ☁️ (us-east-1)
> ❯ ps auxxxwww|grep bacula
> bacula
Hi,
Commits over the last couple of days and ones happening
over the next few days change the internal KPI between
the nfs modules (nfscommon.ko, nfscl.ko and nfsserver.ko).
As such, after pulling an up to date main from the git repo
you need to build all nfs modules from the new sources.
I am
Miroslav Lachman <000.f...@quip.cz> wrote:
> On 24/01/2022 16:13, Rick Macklem wrote:
>
[...]
>
> > So, I think Mark and Yuri are correct and looking at up to date
> > Illumos sources is the next step.
> > (As I mentioned, porting the Apple sources is beyond w
Mark Johnston wrote:
> On Thu, Jun 09, 2022 at 07:49:53PM +0000, Rick Macklem wrote:
> > Mark Johnston wrote:
> > >
> > > On Thu, Jun 09, 2022 at 07:30:47PM +, Rick Macklem wrote:
> > > > I just tried to MFC a commit done to fix my commit by imp@
>
Mark Johnston wrote:
>
> On Thu, Jun 09, 2022 at 07:30:47PM +, Rick Macklem wrote:
> > I just tried to MFC a commit done to fix my commit by imp@
> > and it won't let be push the cherry-pick.
> >
> > What's the trick to doing this?
>
> You need to add --p
I just tried to MFC a commit done to fix my commit by imp@
and it won't let be push the cherry-pick.
What's the trick to doing this?
Or do I need to get Warner to do it?
If so, it's 393b7606f9c1 in main, that needs to go into stable/13.
rick
ps: The stable/13 build will be broken until this gets
Rick Macklem wrote:
> Ronald Klop wrote:
> > Hi,
> >
> > A google search gives me this page:
> > https://forums.freebsd.org/threads/username-length-16.28189/ .
> > It talks about MAXLOGNAME and limits in utmp.
> Yep, I had forgotten about that one.
name and see what happens, at least for the
local
/etc/group file case.
Thanks, rick
Regards,
Ronald
Van: Rick Macklem
Datum: 13 april 2022 03:08
Aan: freebsd-current
Onderwerp: Sanity limit for length of user/group names?
Hi,
The NFSv4 RFCs do not specify an upper limit for the length
of a us
Hi,
The NFSv4 RFCs do not specify an upper limit for the length
of a user or group (called Owner/Owner_group in NFSv4) string.
However, PR#260546 notes that a sanity upper limit for their
length is needed.
Is there any constant in FreeBSD that defines the upper limit for
the length of a user or
John Baldwin wrote:
> On 3/10/22 8:14 AM, Mateusz Guzik wrote:
>> On 3/10/22, Bjoern A. Zeeb wrote:
>>> Hi,
>>>
>>> I am having a weird issue with ktrace on an nfsroot machine:
>>>
>>> root:/tmp # ktrace sleep 1
>>> root:/tmp # kdump
>>> -559038242 Events dropped.
>>> kdump: bogus length
Rick Macklem wrote:
> John Baldwin wrote:
> > On 3/10/22 8:14 AM, Mateusz Guzik wrote:
> > > On 3/10/22, Bjoern A. Zeeb wrote:
> > >> Hi,
> > >>
> > >> I am having a weird issue with ktrace on an nfsroot machine:
> > &
John Baldwin wrote:
> On 3/10/22 8:14 AM, Mateusz Guzik wrote:
> > On 3/10/22, Bjoern A. Zeeb wrote:
> >> Hi,
> >>
> >> I am having a weird issue with ktrace on an nfsroot machine:
> >>
> >> root:/tmp # ktrace sleep 1
> >> root:/tmp # kdump
> >> -559038242 Events dropped.
> >> kdump: bogus
Oh, and you can have netgroups in netgroups, so you can
do something like...
net0 net1,net2
net1 (host1,,),(host2,,)
net2 (host3,,),(host4,,)
then net0 has all 4 hosts in it.
I think you need to break the large netgroup up into sub netgroups
where each one is <= 1024 bytes long.
rick
"man 5 netgroup" notes that a netgroup line is limited to
1024bytes.
Are you sure you haven't just exceeded this limit?
rick
From: owner-freebsd-curr...@freebsd.org on
behalf of Yasuhiro Kimura
Sent: Tuesday, March 15, 2022 12:48 PM
To:
of the University of Guelph. Do not
click links or open attachments unless you recognize the sender and know the
content is safe. If in doubt, forward suspicious emails to ith...@uoguelph.ca
On 22/01/2022 23:20, Rick Macklem wrote:
> Mark Saad wrote:
> [stuff snipped]
>> So I am looking
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 .
>
>
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
From: Miroslav Lachman <000.f...@quip.cz>
Sent: Monday, January 10, 2022 10:27 AM
To: Rick Macklem; freebsd-current@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 Univ
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-current@freebsd.org; freebsd-stable
Cc: Yuri
Subject:
Zaphod Beeblebrox wrote:
> Is the NFS mounted filesystem NFS?
> I've found NFS mounted ZFS has several
> pathologies like this when there is no SSD cache and/or log vdevs attached.
Just fyi, I've recently committed a change to main that changes the NFS
client so that it does append writes
Alexander Leidinger wrote:
> Rick Macklem wrote:
[stuff snipped]
> >
> > 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 coul
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
Hi,
There are two problems with Allocate in the NFSv4.2 server in FreeBSD13:
1 - It uses the thread credentials instead of the ones for the RPC.
2 - It does not ensure that file changes are committed to stable storage.
These problems are fixed by commit f0c9847a6c47 in main, which added
ioflag
Hi,
PR#254282 reports a problem where nullfs mounts cannot be
exported via mountd for FreeBSD 13.0.
The problem seems to be that, to do the nullfs mounts in
/etc/fstab, they require the "late" mount option, so that the
underlying filesystem is mounted (ZFS for the PR).
Adding "mountlate" to the
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
>
Hi,
PR#259163 reports a problem w.r.t. the NFSv3 server that surfaced when
the server was upgraded from 12.2-p8 to 12.2-p9.
I know that nothing changed in NFS server code, but how can I find out
what did get changed by that update?
Thanks in advance for any help, rick
Alan Somers wrote:
[stuff snipped]
>Rick Macklem wrote:
> >Alan Somers wrote:
> > >Yes. posix_fallocate is supposed to guarantee that subsequent writes
> > >to the file will not fail with ENOSPC. But ZFS, being a copy-on-write
> > >file system, cannot possi
1 - 100 of 691 matches
Mail list logo
