in of about 33 mbufs of
various lengths, including a mix of partial clusters and regular
data mbufs, whereas a bulk send on a socket will typically
result in an mbuf chain of a lot of full 2K clusters.
--> As such, NFS can be good at tickling subtle bugs it the
net driver related to mbuf hand
Mark Millard wrote:
>On 2021-May-20, at 22:19, Rick Macklem wrote:
[stuff snipped]
>> ps: I do not think that r367492 could cause this, but it would be
>> nice if you try a kernel with the r367492 patch reverted.
>> It is currently in all of releng13, stable
Ok, so it isn't related to "soft".
I am wondering if it is something specific to what
"diff -r" does?
Could you try:
# cd /usr/ports
# ls -R > /tmp/x
# cd /mnt
# ls -R > /tmp/y
# cd /tmp
# diff -u -p x y
--> To see if "ls -R" finds any difference?
rick
oft mount.
You can revert the patch in r367492 to avoid the problem.
Disabling TSO, LRO are also de-facto standard things to do when
you observe weird NFS behaviour, because they are often broken
in various network device drivers.
rick
From: ow
Mark Millard wrote:
>[I warn that I'm a fairly minimal user of NFS
>mounts, not knowing all that much. I'm mostly
>reporting this in case it ends up as evidence
>via eventually matching up with others observing
>possibly related oddities.]
>
>I got the following odd sequence (that I've
>mixed notes
Rick Macklem wrote:
>Hi,
>
>I posted recently that enabling delegations should be avoided at this time,
>especially if your FreeBSD NFS server has Linux client mounts...
>
>I thought some of you might be curious why, and I thought it would be
>more fun if you look for yourselv
yet upgraded my kernel and tested this.
Have fun with it, rick
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
, delegations seldom improve performance,
so following the above recommendations should not be
a big problem.
rick
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to &quo
usr/bin", remove the obvious essential
ones and have a survey to determine what else is widely used/needed?
>For each removal or deprecation, please consider, is this worth holding
>the project back for?
>
># /etc/src.conf
>WITHOUT_CRUFT=yes
rick
A+
plementations,
>mostly linked with libc or other libraries and not with ftpd code itself.
>
>Please don't fix what ain't broken. Please.
I'll +1 this.
I find ftpd very handy on my local lan (for example, Windoze has an ftp client).
Since it isn't enabled by default, I
Alan Somers wrote:
>On Mon, Mar 29, 2021 at 3:52 PM Rick Macklem
>mailto:rmack...@uoguelph.ca>> wrote:
>>Hi,
>>
>>The FreeBSD NFS server is broken when handling multiple
>>connections for NFSv4.1/4.2.
>>It incorrectly binds the back channel to a new conn
in a release until 12.3/13.1.
It can be found in Bugzilla PR#254560.
In the meantime, avoid using the "nconnects" option
on Linux client mounts.
Thanks go to Ben Coddington @redhat for diagnosing
this and testing the patch.
Sorry about the breakage, rick
ps: It was done intentionally long ag
ured, you'll see lots of files owned
by "nobody" on the client mounts.
rick
From: Rick Macklem
Sent: Friday, September 18, 2020 7:21 PM
To: Shawn Webb; freebsd-curr...@freebsd.org; freebsd-stable@freebsd.org
Subject: Re: Documentation rega
uot;man exports").
If you explain what inconsistencies are in the docs, maybe someone could
fix them.
rick
Thanks,
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
GPG Key ID: 0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3
ta data).
Of course I have no idea what might speed that up. I would be
tempted to look in ZFS for the "snapshot mounting code", in
case I could find an obvious problem...
rick
> Maybe you can provide more information about your setup:
> Amount of RAM, CPU?
64G, Xeon(R) CPU E3-1240
can't think of why "xid" would have been per-connection (especially since a
connection is a questionable concept for UDP), except that this might have
originated in a userland library and carried into the kernel during porting.
rick
From: Daniel
t;transaction id" they are referring to the svid in the lock RPC message,
I have no idea if it should be unique for lock ops on different files.
What does the spec. say? No idea, since there is no such thing.
Anyhow, using TCP will avoid the DRC and whatever the Netapp filer
thinks w.r.t. the u
ng it to change for a different RPC isn't surprising, the xid's
behaviour is
"underspecified" in the Sun RPC RFC.)
rick
From: Daniel Braniss
Sent: Wednesday, January 8, 2020 12:08 PM
To: Rick Macklem
Cc: Richard P Mackerras; Adam Mc
led the difficult problem of having a "stateful server" and crash
recovery,
which resulted in a much more complex protocol (compare the size of RFC-1813
vs RFC-5661 to get some idea of this).
rick
Cheers
Richard
___
freebsd-stable@freebsd.or
Daniel Braniss wrote:
>> On 21 Dec 2019, at 19:32, Rick Macklem wrote:
>>
>> Daniel Braniss wrote:
>>>> On 20 Dec 2019, at 19:19, Rick Macklem
>>>> >>>mailto:rmack...@uoguelph.ca>> wrote:
>>>>
>>>> Adam McDougall w
Daniel Braniss wrote:
>>On 20 Dec 2019, at 19:19, Rick Macklem
>>>>mailto:rmack...@uoguelph.ca>> wrote:
>>
>>Adam McDougall wrote:
>>>Try changing bool_t do_tcp = FALSE; to TRUE in
>>>/usr/src/sys/nlm/nlm_prot_impl.c, recompile the kernel and
;temporarily. I can provide some more details if it works.
If this fixes the problem, please let me know.
I'm not sure I'd want to change the default, since it might break things for
others, but I can definitely make it a tunable, so that people don't need to
recompile a kernel to deal
table, I’m now checking if it’s
>also
>happening on 12.1
>btw, the NetApp version is 9.3P17
Yes. I wasn't the author of the NSM and NLM code (long ago I refused to even
try to implement it, because I knew the protocol was badly broken) and I avoid
fiddling with. As such, it won't hav
st NFS version supported
by
the server by default. (I suspect some are using NFSv4.1 without realizing it,
which isn't necessarily bad.)
nfsstat -m
will show you which version is actually in use for both FreeBSD and Linux.
rick
Cheers
Richard
(NetApp admin)
On Wed, 18 Dec 2019 at 15:46,
need to be seen by other clients, try NFSv4 mounts. Netapp filers
should support NFSv4.1, which is a much better protocol that NFSv4.0.
Good luck with it, rick
…
any ideas?
thanks,
danny
___
freebsd-stable@freebsd.org mailing list
https://
t be worth a try, if you can do it?
Good luck with it, rick
From: owner-freebsd-...@freebsd.org on behalf
of Paul
Sent: Saturday, October 19, 2019 12:09 PM
To: michael.tue...@lurchi.franken.de; freebsd-...@freebsd.org;
freebsd-stable@freebsd.org
Sub
e new capability of incrementally updating the exports in the kernel upon a
reload is only enabled if mountd is started with the new "-I" option the
patch adds.)
If anyone can test the patch (it is the attachment in the PR), please let me
know how
it goes
y build kernels without doing "make buildkernel" and I've found I need
LD=lld SRCTOP= on the make commands.
(or something close to that. I haven't done this since December.)
I haven't tried, but I assumed "make buildkernel" takes care of this "behind the
cu
4 (socket 775), 686 class Celeron (socket 370).
>
> My guvnor, I have zero writable cd media at this time. I grabbed the dvd
> iso:
>FreeBSD-12.0-RC3-i386-dvd1.iso. I can say the boot run its course and served
>up a
>login prompt with considerable aplomb. The contents of /v
bably do this for bfe and fxp, since I have both.
Can someone suggest a good example driver that has already been converted,
so I can see what needs to be done?
Again, I don't care if they stay in the current/head tree.
[more stuff snipped]
rick
uot;sss files" to "files sss", but I'm not sure
>if this would help or not... For now, I simply added the following
>work-around to my /etc/rc.local:
>
> kill -s HUP `cat /var/run/mountd.pid`
That works too. I don't know anything about the libc stuff behind getpwn
erver.
Apparently ESXi 6.7 will only work on newer hardware and I was just wondering
if there is anyone negatively impacted by only supporting ESXi6.7 for NFSv4.1?
Thanks for your comments, rick
___
freebsd-stable@freebsd.org mailing list
Daniel Engel wrote:
[stuff snipped]
>I traced the commits that Rick has made since that thread and merged them
>'head' >into 'stable':
>
>'svnlite checkout http://svn.freebsd.org/base/release/11.1.0/'
>'svnlite merge -c 332790 htt
pipermail/freebsd-stable/2018-March/088486.html>
>
>I traced the commits that Rick has made since that thread and merged them
>'head' >into 'stable':
>
>'svnlite checkout http://svn.freebsd.org/base/release/11.1.0/'
>'svnl
ual consoles, the screen would go blank until I power cycled the SVGA
monitor.
I switched to "sc" and the problem went away.
(This is an old Pentium 4 with what dmesg calls a "Generic VGA display".)
I don't see the same problem with
On Thu, May 10, 2018 at 11:27 AM Ian Lepore wrote:
> On Thu, 2018-05-10 at 14:40 +0000, Rick Miller wrote:
> > On Thu, May 10, 2018 at 8:23 AM Dimitry Andric wrote:
> >
> > >
> > > On 10 May 2018, at 12:47, Rick Miller wrote:
> > > >
> > >
On Thu, May 10, 2018 at 8:23 AM Dimitry Andric wrote:
> On 10 May 2018, at 12:47, Rick Miller wrote:
> >
> > On Thu, May 10, 2018 at 6:35 AM Rick Miller wrote:
> ...
> >> Performing a release build via release/release.sh in r331337 of
> stable/11
> >&g
On Thu, May 10, 2018 at 6:35 AM Rick Miller wrote:
> Hi all,
>
>
>
> Performing a release build via release/release.sh in r331337 of stable/11
> errors citing the lack of lint. It’s understood lint was removed from
> stable/11 so src.conf includes WITHOUT_LINT, but errors p
n
---
*** [llib-lposix.ln] Error code
127
make[5]: stopped in
/data/dists/11.1.9.0-amd64-md/usr/src/usr.bin/xlint/llib
1
error
make[5]: stopped in
/data/dists/11.1.9.0-amd64-md/usr/src/usr.bin/xlint/llib
[1] https://reviews.freebsd.org/D13799?id=37644
As it turns out, it seems EFI must be specified as the boot environment as
opposed to legacy or BIOS+EFI. Setting the boot environment to EFI only
resulted in successful system boot.
Thanks for the replies. The answer came from Allan Jude on Twitter.
On Mon, Mar 12, 2018 at 6:18 PM Rick Miller
ion=4&manpath=FreeBSD+11.1-RELEASE&arch=default&format=html
[2] https://lists.freebsd.org/pipermail/freebsd-hardware/
2013-September/007380.html
[3] http://www.wonkity.com/~wblock/docs/html/disksetup.html
--
Take care
Rick Miller
___
freebsd-sta
will list you as "Tested by:" on the
commits.
(If you don't want me to do this, just email.)
Good luck with the testing, rick
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To un
d up
versions of
them committed in April.
The main outstanding issue is the Readdir one about directory changing too much.
Hopefully I can find out something about it via email.
Have fun with it, rick
___
freebsd-stable@freebsd.org mailing list
https://
ttached one more little patch. If this one is applied after
wantdeleg.patch
and wantdeleg2.patch it might get rid of these. (There was another place
that needed to be changed that got missed by wantdeleg.patch.)
Have fun with it, rick
wantdeleg3.patch
Description: wantdeleg3.patch
_
c=1 won't have any
affect.
If you apply the attached patch, it should change the FILESYNC->UNSTABLE so
that vfs.nfsd.async=1 will make a difference. Again, doing this does put data
at risk when the server crashes.
rick
writeasync.patch
Description: writeasync.patch
___
361: BUG - Invalid BIND_CONN_TO_SESSION error: >NFS4ERR_NOTSUPP
The attached patch changes BindConnectiontoSession to reply
NFS4ERR_BAD_SESSION when the session doesn't exist. This might trigger
recovery after a server reboot.
This patch must be applied after bindconn.patch.
rick
bindconn2.patch
De
The other thing that might help for UFS is increasing the size of the buffer
cache.
(If this server is mainly an NFS server you could probably make the buffer cache
greater than half of the machine's ram.
Note to others, since ZFS doesn't use the buffer cache, the opposite is true
f
uot;/")
>2018-03-07T16:46:04.546Z cpu12:68008 opID=55bea165)NFS41:
>>NFS41_VSIMountSet:435: nfsds1 mounted successfully
>2018-03-07T16:47:19.869Z cpu21:67981 opID=e47706ec)World: 12235: VC opID
>>c55dbe91 maps to vmkernel opID e47706ec
>2018-03-07T16:47:19.86
do and I can probably have
a patch for testing in a day or two.
rick
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
g a delegation, so the wantdeleg*.patches probably aren't very
interesting.
rick
wantdeleg2.patch
Description: wantdeleg2.patch
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscrib
the
server right now.
rick
[stuff snipped]
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Nope, that isn't supported, rick
(Hope no one is too upset by a top post.)
From: NAGY Andreas
Sent: Monday, March 5, 2018 8:22:10 AM
To: Rick Macklem; 'freebsd-stable@freebsd.org'
Subject: RE: NFS 4.1 RECLAIM_COMPLETE FS failed error in c
ec. My driver allowed CSRG to convince DEC to give them
their driver from Ultrix, but it wasn't much better.
(When I retired a few years ago, I still had a MicroVAXII sitting under my desk,
mostly as a joke. It was sooo sllooo, but it would still boot some variant
of 4BSD.)
rick
#x27;t think it matters
much, since it is just complaining about the "reason" the server returns for
not issuing a delegation (issuing delegations is entirely at the discretion of
the server and is disabled by default).
[more stuff snipped]
Good luck with it, rick
wantdeleg.patch
Descriptio
would look like:
if (*tl == newnfs_true)
nd->nd_repstat = NFSERR_NOTSUPP;
else
nd->nd_repstat = nfsrv_checkreclaimcomplete(nd);
whereas after being patched, it will look like:
nd->nd_repstat = nfsrv_checkreclaimcom
about this.
So, feel free to test with the attached patch and if you run into problems
with the mount, email w.r.t. what they are. If we persevere we might get it
going ok.
rick
[stuff snipped]
reclaimcom2.patch
Description: reclaimcom2.patch
related things break
within jails, so fixing the nfsuserd situation may not resolve your problems.
rick
From: Fabian Freyer
Sent: Sunday, October 15, 2017 4:45:00 PM
To: freebsd-stable@freebsd.org
Cc: Rick Macklem; li...@searchy.net; z...@physik.tu
net driver issues.
This shouldn't be a problem with an iX Systems box, since they test it with
FreeNAS
(based on FreeBSD).
Maybe the folk that made hardware suggestions can post which net interface(s)
they are using and whether they are seeing driver issues?
Good luck with it, rick
. extended attribute namespace for fuse filesystems, since fuse doesn't
support the notion of a namespace.
Just a suggestion. I have no strong opinion on this, rick
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Claude Buisson wrote:
>On 05/07/2017 21:09, Rick Macklem wrote:
>> Claude Buisson wrote:
>>> Hi,
>>>
>>> Last month, I started switching all my systems (stable/9, stable/10,
>>> stable/11 and current) to NFSv4, and I found that:
>>>
>
he NFS4 case. But:
Yes, I would say all that is needed is the call to add_mtab() in mount_nfs.c be
made
conditional on a non-NFSv4 mount.
Thanks for reporting this, rick
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/lis
oes not use the
Mount protocol. I am not sure why your NFSv4 mounts are putting an entry in
mounttab, since that is done by mountd.c on the server and the client isn't even
contacting it?
rick
___
freebsd-stable@freebsd.org mailing list
https://lists
d require a major redesign
of the FreeBSD VFS to make it fully stackable to fix unionfs and that isn't
happening
anytime soon...
Harry Schmalzbauer wrote:
> In 2016 I did some tests with 11.0-Beta1, where this thread origins, and
> Rick kindly looked into it and provided the followi
Hmm, this is going to sound dumb, but I don't recall generating any
unionfs patch;-)
I'll go look for it. Maybe it was Kostik's?
rick
From: Harry Schmalzbauer
Sent: Tuesday, March 7, 2017 2:45:40 PM
To: Rick Macklem
Cc: Konstantin Belousov;
_) thread 0xf800055e3a00 (100079)
> shared lockmgr ufs (ufs) r = 0 (0xf8000523d5f0) locked @
> /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/vfs_lookup.c:611
> Process 594 (negotiate_kerberos_) thread 0xf80005599000 (100072)
> shared lockmgr ufs (ufs) r = 0 (0xff
meaningless.
Even for NFSv3, all they do is provide a "best guess" answer for
"showmount".
- The Mount protocol is not part of NFSv4. I had a patch which disabled
it for NFSv4 servers, but some folk liked the idea of having "showmount -e"
to work, so I didn't co
Do you have exactly the same export options specified in /etc/exports
for the 9.3 server as the 6.3 one?
Beyond that, I can only suggest capturing packets when the automount fails
and looking at them in wireshark to see what is actually happening.
rick
Sorry, I forgot that the userland commits were needed as soon as the kernel
commit went in. I have just done the userland commits and things should be
fixed now. (I don't know what r305146 is, but I don't think it is related to
this.)
Again, sorry for breaking the b
Harry Schmalzbauer wrote:
>Bezüglich Rick Macklem's Nachricht vom 18.08.2016 02:03 (localtime):
>> Kostik wrote:
>> [stuff snipped]
>>> insmnque() performs the cleanup on its own, and that default cleanup isnot
>>> suitable >for the situation.
like it does the required
stuff (unionfs_noderem() is what the unionfs VOP_RECLAIM() does).
It switches the node back to using its own v_vnlock that is exclusively locked,
among other things.
rick
unionfs-newvnode.patch
Description: unionfs-newvnode.patch
__
has been initialized.
(This means that the cleanup if it fails is more involved, but...)
I've attached a patch (untested) that does this. Maybe you could try it?
rick
ps: I've cc'd Kostik, in case he has some insight w.r.t. how this should be
handled?
unionfs-newvnode.patch
ld
have done so long ago. Yes, some use it successfully, but if not...
Sorry, but I suspect that is how it will remain, rick
Unread portion of the kernel message buffer:
panic: __lockmgr_args: downgrade a recursed lockmgr nfs @
/usr/local/share/deploy-tools/RELENG_11/src/sys/fs/unionfs/union_vnops.c:1
On Wed, Apr 27, 2016 at 5:37 PM, Slawa Olhovchenkov wrote:
> On Wed, Apr 27, 2016 at 01:00:19PM -0400, Rick Miller wrote:
>
> > Hi all,
> >
> > Building stable/10@r298482 errors when executing newfs_msdos on
> > uefi-disc1.iso as shown below. It is being built
: stopped in /usr/src/release
--
Take care
Rick Miller
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Frank de Bot wrote:
> Rick Macklem wrote:
> > Frank de Bot wrote:
> >> Rick Macklem wrote:
> >>> Frank de Bot wrote:
> >>>> Hi,
> >>>>
> >>>> On a 10.1-RELEASE-p9 server I have several NFS mounts used for a
> >
"ls -l" should be sufficient. (Doing it just
after mounting will avoid any attribute cache hit.)
You could then look at the fifo.pcap in wireshark (or email it to me as an
attachment and I can look) and see if the file type attribute is FIFO.
(If it isn't,
the high order bits of va_mode
(the S_IFMT bits). I don't have ZFS to test with.
2 - You somehow used an NFSv2 mount. (NFSv2 didn't have support for FIFOs,
if I recall correctly.)
You can check your mount options, including which version is in use via
"nfsstat -m"
that file. This is not that unlikely if large directory trees are
> copied during that time.
>
Oops, thanks. I didn't know that [fifoor] in these lines meant that was what
the WCHAN is. Obviously, you should now ignore everything I said;-)
rick
> On the other hand, cp without -R/
ecent
em(4) driver is fixed.)
You can also do things like `netstat -m` to look for mbuf cluster exhaustion
and look at the stats for your net driver (usually a sysctl).
Good luck with it, rick
> There is nothing in the logs on the new system, but the old one has a
> number of entries like:
>
Christian Kratzer wrote:
> Hi Rick,
>
> On Sun, 18 Oct 2015, Rick Macklem wrote:
>
> > Christian Kratzer wrote:
> >> Hi Rick,
> >>
> >> looks like your latest patch nailed the issue. The box has been up for 3
> >> days:
> >>
>
Christian Kratzer wrote:
> Hi Rick,
>
> looks like your latest patch nailed the issue. The box has been up for 3
> days:
>
> ck@noc3:~ % uptime
> 12:22PM up 3 days, 4:11, 1 user, load averages: 0.07, 0.10, 0.08
> ck@noc3:~ %
>
> If it does not cra
Christian Kratzer wrote:
> Hi Rick,
>
> looks like your latest patch nailed the issue. The box has been up for 3
> days:
>
> ck@noc3:~ % uptime
> 12:22PM up 3 days, 4:11, 1 user, load averages: 0.07, 0.10, 0.08
> ck@noc3:~ %
>
> If it does not cra
Christian Kratzer wrote:
> Hi Rick,
>
> On Mon, 12 Oct 2015, Rick Macklem wrote:
>
> > Christian Kratzer wrote:
> >> Hi Rick,
> >>
> >> there was also a second more recent crash in /var/crash
> >>
> >> Mon Oct 12 03:01:16 CEST
Christian Kratzer wrote:
> Hi Rick,
>
> there was also a second more recent crash in /var/crash
>
> Mon Oct 12 03:01:16 CEST 2015
>
> FreeBSD noc3.cksoft.de 10.2-STABLE FreeBSD 10.2-STABLE #2 r288980M: Sun
> Oct 11 08:37:40 CEST 2015
> c...@noc3
Hi again,
Attached is a semantically equivalent patch to the one I posted a few
minutes ago, but I think this one is more readable.
Please let me know if you get it tested, rick
- Original Message -
> Hi John,
>
> the box crashed again running a 10-stable kernel with following
Hi,
Maybe you could try the attached patch instead of the one below?
(Completely untested. I haven't even tried to compile it.)
rick
- Original Message -
> Hi John,
>
> the box crashed again running a 10-stable kernel with following patch of
> yours:
>
> O
), smb_iod_destroy() can go ahead and destroy the
mtuexes.
I think the above patch failed because the smb_iod_sendall(iod) and
smb_iod_recvall(iod)
need to be done before smb_iod_main() returns.
I'll email a patch for testing later to-day (I've gotta run and do something
else now), rick
&
ne asked me to MFC r287775 to 10.X release aswell. Is this still
> required?
>
> --HPS
Thanks for doing this, rick
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsub
e has some insight.
If you don't get any responses, I'd suggest reposting to freebsd-current@ with
"crashes in mtx_unlock(&Giant)" in the subject line.
Btw John, the code does tsleep() in a loop before the mtx_unlock(&Giant). I do
remember that was once allowed, but am no
Frank de Bot wrote:
> Rick Macklem wrote:
> > Frank de Bot wrote:
> >> Rick Macklem wrote:
> >>> Frank de Bot wrote:
> >>>> Hi,
> >>>>
> >>>> On a 10.1-RELEASE-p9 server I have several NFS mounts used for a
> >
Frank de Bot wrote:
> Rick Macklem wrote:
> > Frank de Bot wrote:
> >> Rick Macklem wrote:
> >>> Frank de Bot wrote:
> >>>> Hi,
> >>>>
> >>>> On a 10.1-RELEASE-p9 server I have several NFS mounts used for a
> >
Frank de Bot wrote:
> Rick Macklem wrote:
> > Frank de Bot wrote:
> >> Hi,
> >>
> >> On a 10.1-RELEASE-p9 server I have several NFS mounts used for a
> >> jail.
> >> Because it's a server only to test, there is a low load. But the
>
e change, but there isn't a sysctl
for it (maybe there should be?).
rick
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ead of
10.13.37.
- Write a daemon that does a stat() of a file on the NFS mount once per minute,
so the NFS connection is never idle long enough to be disconnected.
rick
> 10.2-RELEASE #0 r28 is the current running version.
>
> Regards,
>
> Frank de Bot
>
s thread:
http://docs.FreeBSD.org/cgi/mid.cgi?55DC1B5A.8010109
rick
>
>
> cu
> Gerrit
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/free
Daniel Braniss wrote:
>
> > On 24 Aug 2015, at 10:22, Hans Petter Selasky wrote:
> >
> > On 08/24/15 01:02, Rick Macklem wrote:
> >> The other thing is the degradation seems to cut the rate by about half
> >> each time.
> >> 300-->
Daniel Braniss wrote:
>
> > On 22 Aug 2015, at 14:59, Rick Macklem wrote:
> >
> > Daniel Braniss wrote:
> >>
> >>> On Aug 22, 2015, at 12:46 AM, Rick Macklem wrote:
> >>>
> >>> Yonghyeon PYUN wrote:
> >>>>
Daniel Braniss wrote:
>
> > On Aug 22, 2015, at 12:46 AM, Rick Macklem wrote:
> >
> > Yonghyeon PYUN wrote:
> >> On Wed, Aug 19, 2015 at 09:00:35AM -0400, Rick Macklem wrote:
> >>> Hans Petter Selasky wrote:
> >>>> On 08/19/15 09:42, Yo
Yonghyeon PYUN wrote:
> On Wed, Aug 19, 2015 at 09:00:35AM -0400, Rick Macklem wrote:
> > Hans Petter Selasky wrote:
> > > On 08/19/15 09:42, Yonghyeon PYUN wrote:
> > > > On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote:
> > > &
Yonghyeon PYUN wrote:
> On Wed, Aug 19, 2015 at 08:13:59AM -0400, Rick Macklem wrote:
> > Yonghyeon PYUN wrote:
> > > On Wed, Aug 19, 2015 at 09:51:44AM +0200, Hans Petter Selasky wrote:
> > > > On 08/19/15 09:42, Yonghyeon PYUN wrote:
> > > > >On Wed,
1 - 100 of 460 matches
Mail list logo
