Lars Eggert wrote:
Hi,
every few days or so, my -STABLE NFS server (v3 and v4) gets wedged
with a ton of messages about nfsd server cache flooded, try to
increase nfsrc_floodlevel in the log, and nfsstat shows TCPPeak at
16385. It requires a reboot to unwedge, restarting the server does
Slawa Olhovchenkov wrote:
Its posible use currentle FreeBSD on NFS_V4 root?
Explain:
pxeboot do NFS_v3 (not NFS_v4) mount and pass fd to kernel.
In this setup kernel can use only configured (established) nfs fh.
This is not allowed to switch version or some options.
When pxeboot use
Allan Jude wrote:
On 2013-10-13 15:10, Olivier Cochard-Labbé wrote:
I've got a frequent problem on my desktop (FreeBSD 10.0-ALPHA5 #8
r256200):
After few hours I can't acces to one of my folder: A simple ls in
this folder stucks, and all filesystem information started after
(df,
Hi,
I just tried to MFC into stable/10 and it worked, but with
a lot of mergeinfo. I know diddly about svn, so is this ok?
Here's the svn diff:
Index: sys
===
--- sys (revision 259205)
+++ sys (working copy)
Property changes on:
Eitan Adler wrote:
On Tue, Dec 10, 2013 at 7:04 PM, Rick Macklem rmack...@uoguelph.ca
wrote:
Hi,
I just tried to MFC into stable/10 and it worked, but with
a lot of mergeinfo. I know diddly about svn, so is this ok?
Starting with stable/10 and later you must merge into the *root
Berislav Purgar wrote:
Hello
I have problem with NFS on current.
Timecounters tick every 10.000 msec
ada0 at ata0 bus 0 scbus0 target 0 lun 0
ada0: ST640211CF 3.07 CFA-0 device
ada0: Serial Number 3ME3GRCZ
ada0: 16.700MB/s transfers (PIO4, PIO 8192bytes)
ada0: 3906MB (7999488
Grzegorz Bernacki wrote:
Hi,
After rebasing to new -current I experienced problem with mounting
root
via NFS. I was getting error: Mounting from nfs: failed with error 2:
unknown file system.. I use BOOTP and NFSv3 (option NFSCLIENT). It
seems that bootp set fs type to 'nfs' and recently
Hi Rick,
The problem is that in embedded development sometimes loader is not
used. And in that case we would like to have possibity to use old NFS
client without patching code every time. So if you don't mind I would
like to commit the patch.
I also will try new nfs client and let you
Steve Kargl wrote:
So, I upgraded a system from Feb 10 -current to today's
-current code. In doing so, I changed the kernel config
options from
options NFSCLIENT # Network Filesystem Client
options NFSSERVER # Network Filesystem Server
to
options NFSCL # Network Filesystem Client
Steve Kargl wrote:
On Wed, Jul 06, 2011 at 05:02:37PM -0700, Garrett Cooper wrote:
On Wed, Jul 6, 2011 at 4:57 PM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
So, I upgraded a system from Feb 10 -current to today's
-current code. ?In doing so, I changed the kernel config
Although deleting /etc/rc.d/nfsserver is probably all you need
to do if you have head/etc/rc.d/nfsd, I've attached an updated
nfsd script that I am waiting for a review of.
If you'd like to test this (when /etc/rc.d/nfsserver is deleted),
it would be appreciated.
I think it will work for your
m...@freebsd.org wrote:
On Mon, Jul 11, 2011 at 4:00 PM, Ali Mashtizadeh
mashtiza...@gmail.com wrote:
Maybe someone can setup something like reviewboard [1] for
developers
to use. This may also help folks who want to keep abreast of the
current work in a particular subsystem or get
Steve Kargl wrote:
On Mon, Jul 25, 2011 at 01:00:27PM +0300, Andriy Gapon wrote:
on 12/07/2011 11:05 Andriy Gapon said the following:
I think that the best thing you can further provide (as objective
evidence for
the problem at hand) is ktr(4) traces for at least KTR_SCHED mask.
Andriv Gapon wrote:
on 26/07/2011 00:44 Rick Macklem said the following:
hrs sent me this panic. I'm wondering if it might be relevant to
this?
To 'this' what?
Well, my thinking was (and it is quite likely completely incorrect) is
that, since this panic is a result of holding the spin
Andriy Gapon wrote:
on 31/07/2011 01:55 Rick Macklem said the following:
Andriv Gapon wrote:
on 26/07/2011 00:44 Rick Macklem said the following:
hrs sent me this panic. I'm wondering if it might be relevant to
this?
To 'this' what?
Well, my thinking was (and it is quite likely
Abdriy Gapon wrote:
on 31/07/2011 22:03 Rick Macklem said the following:
Ok, so if the scheduler spin lock is being held too long, what could
cause this, if it isn't a scheduler bug?
I can't think of how NFS would affect this beyond causing a heavy
I/O
load, but if there is some way
Boris Samorodov wrote:
Hi!
I use the same kernel for both host and diskless stations.
The FreeBSD-9 r224471 kernel at the host system works fine,
but the r224870 kernel oes not work. The file /pxeboot seems to be
loaded but then the host system does not answer to client's nfs
questions.
Boris Samorodov wrote:
On Mon, 15 Aug 2011 18:26:28 -0400 (EDT) Rick Macklem wrote:
Please try this one line patch:
(I see that the patch was already commited)
The patch worked for me, thanks!
Good. Thanks for reporting the problem and testing the patch, rick
Hiroki Sato wrote:
Hiroki Sato h...@freebsd.org wrote
in 20110819.002046.908756241495481148@allbsd.org:
hr Hi,
hr
hr I have experienced Stale NFS file handle issue when switching
hr between oldnfs and newnfs on a CURRENT box (NFS server exporting
ZFS
hr mountpoints). The cause was
Hiroki Sato wrote:
Hiroki Sato h...@freebsd.org wrote
in 20110819.002046.908756241495481148@allbsd.org:
hr Hi,
hr
hr I have experienced Stale NFS file handle issue when switching
hr between oldnfs and newnfs on a CURRENT box (NFS server exporting
ZFS
hr mountpoints). The cause was
Hiroki Sato wrote:
Rick Macklem rmack...@uoguelph.ca wrote
in 1565511281.69213.1313764157732.javamail.r...@erie.cs.uoguelph.ca:
rm Hiroki Sato wrote:
rm fsid_guid = dmu_objset_fsid_guid(zfsvfs-z_os);
rm ASSERT((fsid_guid ~((1ULL56)-1)) == 0);
rm vfsp-vfs_fsid.val[0] = fsid_guid;
rm
Hiroki Sato wrote:
Rick Macklem rmack...@uoguelph.ca wrote
in 1565511281.69213.1313764157732.javamail.r...@erie.cs.uoguelph.ca:
rm Hiroki Sato wrote:
rm fsid_guid = dmu_objset_fsid_guid(zfsvfs-z_os);
rm ASSERT((fsid_guid ~((1ULL56)-1)) == 0);
rm vfsp-vfs_fsid.val[0] = fsid_guid;
rm
Benjamin Kaduk wrote:
On Sat, 20 Aug 2011, Rick Macklem wrote:
Yes, using vfs_getnewfsid() does not solve the issue.
I noticed that Solaris looked up a fixed array vfssw[] exactly for
the purpose. I think a table like it is a good solution for fixing
fsid for each file system
John De wrote:
Hi,
I have an nfs server running 9-current. Everything works as far
as nfs i/o operations are concerned.
From another FreeBSD box, nfs locking works great to the server
when addressed by both it's real ip address and it's aliased ip
address.
From a Linux system:
Benjamin Kaduk wrote:
On Sun, 21 Aug 2011, Rick Macklem wrote:
Benjamin Kaduk wrote:
On Sat, 20 Aug 2011, Rick Macklem wrote:
If anyone thinks using a fixed table to assign vfc_typenum for
known
file system types is a bad idea, please let us know.
Fixed table sounds like a good
Pawel Jakub Dawidek wrote:
On Sat, Aug 20, 2011 at 08:15:34PM -0400, Rick Macklem wrote:
Hiroki, could you please test the attached patch.
One problem with this patch is that I don't know how to create a
fixed
table that matches what systems would already have been getting.
(I got
Pawel Jakub Dawidek wrote:
On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote:
Ok, I'll admit I wasn't very fond of a fixed table that would
inevitably
get out of date someday, either.
I didn't think hashing for the cases not in the table was worth the
effort,
but doing
Kostik Belousov wrote:
On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote:
On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote:
Pawel Jakub Dawidek wrote:
On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote:
Ok, I'll admit I wasn't very fond
:11:20PM -0400, Rick Macklem wrote:
ko Pawel Jakub Dawidek wrote:
koOn Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem
wrote:
ko Ok, I'll admit I wasn't very fond of a fixed table that
would
ko inevitably
ko get out of date someday, either.
ko
ko I
Pawel Jakub Dawidek wrote:
On Wed, Aug 24, 2011 at 04:41:25PM +0300, Kostik Belousov wrote:
On Wed, Aug 24, 2011 at 09:36:37AM -0400, Rick Macklem wrote:
Well, doesn't this result in the same issue as the fixed table?
In other words, the developer has to supply the suggested byte
Pawel Jakub Dawidek wrote:
On Wed, Aug 24, 2011 at 04:41:25PM +0300, Kostik Belousov wrote:
On Wed, Aug 24, 2011 at 09:36:37AM -0400, Rick Macklem wrote:
Well, doesn't this result in the same issue as the fixed table?
In other words, the developer has to supply the suggested byte
Benjamin Kaduk wrote:
On Wed, 24 Aug 2011, Rick Macklem wrote:
afs
The current OpenAFS codebase uses the all-caps AFS. Judging by the
omitted text, perhaps this should change. (We also don't use VFS_SET
to
set it, which I filed a bug about.)
and here is my current rendition
Benjamin Kaduk wrote:
If we're confident that we won't ever fully fill the hash table, I
would
think that this should wrap around back to zero (or one?) instead of
overflowing.
Here's my updated patch (it will wrap to 1 the first time and then
exceed 255 if 1-255 are all in use).
---
John wrote:
After pondering the best way to allow the VOP_ACCESS() call to
only query for the permissions really needed, I've come up with
a patch that minimally adds one parameter to the nlm_get_vfs_state()
function call with the lock type from the original argp.
Steve Wills wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/26/11 22:16, Steve Wills wrote:
On 08/26/11 21:41, Steve Wills wrote:
Hi,
I'm trying to use 9.0-CURRENT as an NFS server for a VMWare ESXi
4.1.0.
When I attempt the mount, it logs this message:
The NFS
Steve Wills wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/27/11 09:00, Rick Macklem wrote:
This line indicates that mountd over tcp is registered for v3,
so I suspect the error message is misleading??
Forgot to reply to this part, and I should have been more clear
earlier
Steve Wills wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/26/11 22:16, Steve Wills wrote:
On 08/26/11 21:41, Steve Wills wrote:
Hi,
I'm trying to use 9.0-CURRENT as an NFS server for a VMWare ESXi
4.1.0.
When I attempt the mount, it logs this message:
The NFS
Steve Wills wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/27/11 21:23, Steve Wills wrote:
On 08/27/11 20:55, Rick Macklem wrote:
I don't know why the nfsd wouldn't be able to bind(2) to port
#2049 a
second time for UDP, but someone on the net side might know? (Just
Brandon Gooch wrote:
On Thu, Sep 1, 2011 at 8:09 PM, Brandon Gooch
jamesbrandongo...@gmail.com wrote:
On Fri, May 27, 2011 at 8:09 AM, Rick Macklem rmack...@uoguelph.ca
wrote:
On Thu, 26 May 2011, Rick Macklem wrote:
...
http://people.freebsd.org/~rmacklem/dtrace.patch
Hmm
Brandon Gooch wrote:
On Fri, Sep 02, 2011 at 08:25:05PM -0400, Rick Macklem wrote:
Brandon Gooch wrote:
On Thu, Sep 1, 2011 at 8:09 PM, Brandon Gooch
jamesbrandongo...@gmail.com wrote:
On Fri, May 27, 2011 at 8:09 AM, Rick Macklem
rmack...@uoguelph.ca
wrote:
On Thu, 26 May
Lev Serebryakov wrote:
Hello, Freebsd-current.
I've built NanoBSD image for my router based on latest HEAD sources.
Image contains minimal set of kernel modules and custom kernel with
NFSCLIENT option.
Router mounts /usr/home via NFS with this /etc/fstab line:
192.168.134.2:/usr/home
Hiroki Sato spotted a problem with NFS server file handles (FHs)
changing after a server upgrade, because the exported file
system type(s) get configured in a different order and, therefore,
assigned different vfs_typenum values.
A patch has been worked out, after discussion with various folks,
Harald Schmalzbauer wrote:
schrieb Attilio Rao am 01.10.2011 16:49 (localtime):
Can you please show the panic message?
Sorry, I forgot to add it here:
free indoe /var/123088 had 8 blocks
panic: VAPPEND withour VWRITE
cpuid = 0
KDB: enter: panic
[ thread pid 1445 tid 100126 ]
Bjoern A. Zeeb wrote:
Hi,
as a result of a make buildkernel make installkernel reboot all
on NFS I got this with a HEAD SVN source at r226465. I cannot dump
unfortunately and it seems I just killed the obj tree for this kernel
though it should be very close.
Oct 18 10:03:22 lion3
Dan The Man wrote:
Just want to include some errors from rsync trying to copy files using
NFSV4. These files copy fine using NFSV3
rsync: readlink_stat(/asterisk/public/mp3/Kass Tunes/A-E/A/Ace of
Base/The Bridge/Ace of Base-My D\#351j\#340 Vu-09-The Bridge.wma)
failed:
Invalid
Hi,
I have just committed r227809 to head/current which enables the
new/default NFS server's use of shared vnode locks for Read,
Readdir, Readlink, Getattr and Access.
Although it is hoped that this will improve performance for these
operations when multiple ones are performed concurrently on
Sean Bruno wrote:
Not sure what this all means, but when I attempt to check out HEAD on
an
NFS mount in the fbsd cluster (nfs server is a netapp filer), I'm
getting an odd failure error.
FreeBSD bhyve.freebsd.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0
r227883:
Wed Nov 23 06:08:40 PST 2011
Dinitry Andric wrote:
On 2011-11-23 17:41, Sean Bruno wrote:
Not sure what this all means, but when I attempt to check out HEAD
on an
NFS mount in the fbsd cluster (nfs server is a netapp filer), I'm
getting an odd failure error.
FreeBSD bhyve.freebsd.org 10.0-CURRENT FreeBSD
Dimitry Andric wrote:
On 2011-11-23 17:41, Sean Bruno wrote:
Not sure what this all means, but when I attempt to check out HEAD
on an
NFS mount in the fbsd cluster (nfs server is a netapp filer), I'm
getting an odd failure error.
FreeBSD bhyve.freebsd.org 10.0-CURRENT FreeBSD
Sean Bruno wrote:
On Wed, 2011-11-23 at 09:58 -0800, Rick Macklem wrote:
I don't know if Dimitry tried this, but you could also try the
nolockd option, so that byte range locking is done locally in
the client and avoids the NLM.
Good luck with it and please let us know how it goes, rick
Nov 2011, Rick Macklem wrote:
Dan the Man wrote:
Hey Rick,
I should note I ran client from latest centos release box that has
a
freebsd 9.0 mount, so I am not sure applying a client patch would
do
anything in this case. When I had mounted a nfsv3 mount from
freebsd
box
Pawel Jakub Dawidek wrote:
On Fri, Nov 25, 2011 at 01:20:01PM -0600, Mark Felder wrote:
13:14:32 nas:~ uname -a
FreeBSD nas.feld.me 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #3
r227971M:
Fri Nov 25 10:07:48 CST 2011
r...@nas.feld.me:/usr/obj/tank/svn/sys/GENERIC amd64
This seemed to
John wrote:
After pondering the best way to allow the VOP_ACCESS() call to
only query for the permissions really needed, I've come up with
a patch that minimally adds one parameter to the nlm_get_vfs_state()
function call with the lock type from the original argp.
John wrote:
After pondering the best way to allow the VOP_ACCESS() call to
only query for the permissions really needed, I've come up with
a patch that minimally adds one parameter to the nlm_get_vfs_state()
function call with the lock type from the original argp.
Vincent Hoffman wrote:
Just a note to say I have tested this on -CURRENT with the new nfs
server and it is still the case.
On the client (FreeBSD seaurchin 8.3-RELEASE-p3 FreeBSD 8.3-RELEASE-p3
#0: Tue Jun 12 00:39:29 UTC 2012
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
Vincent Hoffman wrote:
On 01/07/2012 01:53, Rick Macklem wrote:
Vincent Hoffman wrote:
Just a note to say I have tested this on -CURRENT with the new nfs
server and it is still the case.
On the client (FreeBSD seaurchin 8.3-RELEASE-p3 FreeBSD
8.3-RELEASE-p3
#0: Tue Jun 12 00:39:29
Vincent Hoffman wrote:
On 01/07/2012 12:18, Rick Macklem wrote:
Vincent Hoffman wrote:
On 01/07/2012 01:53, Rick Macklem wrote:
To modify mountd to use the kernel changes is more work than I
have
time for, in part because mountd.c is a very ugly old piece of C
code, imho.
I do
Vincent Hoffman wrote:
On 07/07/2012 13:26, Vincent Hoffman wrote:
On 01/07/2012 12:18, Rick Macklem wrote:
Vincent Hoffman wrote:
On 01/07/2012 01:53, Rick Macklem wrote:
To modify mountd to use the kernel changes is more work than I
have
time for, in part because mountd.c is a very
Vincent Hoffman:
On 08/07/2012 00:26, Rick Macklem wrote:
Vincent Hoffman wrote:
Hi Rick,
I'm afraid this didnt make any real difference for me.
Since I couldnt test it on the live system I tried it on a test vm.
on the vm (nfs server) I set a looping mount/umount
while true ; do
if there is an easy way to tell open-sshd
to use the default credential cache file name?
If not, all I can think of is to document this in gssd.8.
Thanks in advance for any help with this, rick
[Herbert Poeckl wrote in an email to me, copied with his permission]
Hi Rick,
On 09/20/2012 11:45 PM, Rick Macklem
Hi,
Hopefully someone familiar with svn can help. When I try to MFC
a kernel change to stable/8, it works, but I end up with tons of
mergeinfo. (It looks like every directory under sys.)
Does this matter or is there a trick to avoid this?
Thanks in advance for any help, rick
ps: I seem to MFC
Sean Bruno wrote:
On Thu, 2012-10-04 at 11:10 -0700, Rick Macklem wrote:
Hi,
Hopefully someone familiar with svn can help. When I try to MFC
a kernel change to stable/8, it works, but I end up with tons of
mergeinfo. (It looks like every directory under sys.)
Does this matter
John Baldwin wrote:
On Thursday, October 04, 2012 2:10:11 pm Rick Macklem wrote:
Hi,
Hopefully someone familiar with svn can help. When I try to MFC
a kernel change to stable/8, it works, but I end up with tons of
mergeinfo. (It looks like every directory under sys.)
Does
Olivier Smedts wrote:
Hi,
2012/11/28 O. Hartmann ohart...@zedat.fu-berlin.de:
Hello,
I have a naive question.
I read about speeding up NFSv4 shared ZFS array. I use a RAIDZ1
volume
made up from 5 times 3TB harddrives, attached to a ICH10 SATA
controller
on a FreeBSD 10.0-CURRENT
I don't believe the patch I just committed to head
for the kernel RPC to add backchannel support or
the NFS client patch coming soon should affect
operation unless the new minorversion=1 is used.
However, since the patch is fairly large, I thought
I'd give everyone a head up, in case it somehow
Adrian Chadd wrote:
.. what was the previous kernel version?
Hopefully Tim has it narrowed down more, but I don't see
the hangs on a Sept. 7 kernel from head and I do see them
on a Dec. 3 kernel from head. (Don't know the eact rNN.)
It seems to predate my commit (r244008), which was my
Konstantin Belousov wrote:
On Mon, Dec 10, 2012 at 01:38:21PM -0500, Rick Macklem wrote:
Adrian Chadd wrote:
.. what was the previous kernel version?
Hopefully Tim has it narrowed down more, but I don't see
the hangs on a Sept. 7 kernel from head and I do see them
on a Dec. 3 kernel
Konstantin Belousov wrote:
On Mon, Dec 10, 2012 at 07:11:59PM -0500, Rick Macklem wrote:
Konstantin Belousov wrote:
On Mon, Dec 10, 2012 at 01:38:21PM -0500, Rick Macklem wrote:
Adrian Chadd wrote:
.. what was the previous kernel version?
Hopefully Tim has it narrowed down
Konstantin Belousov wrote:
On Tue, Dec 11, 2012 at 04:55:52PM -0500, Rick Macklem wrote:
Konstantin Belousov wrote:
On Mon, Dec 10, 2012 at 07:11:59PM -0500, Rick Macklem wrote:
Konstantin Belousov wrote:
On Mon, Dec 10, 2012 at 01:38:21PM -0500, Rick Macklem wrote:
Adrian
Konstantin Belousov wrote:
On Tue, Dec 11, 2012 at 05:30:24PM -0500, Rick Macklem wrote:
Konstantin Belousov wrote:
On Tue, Dec 11, 2012 at 04:55:52PM -0500, Rick Macklem wrote:
Konstantin Belousov wrote:
On Mon, Dec 10, 2012 at 07:11:59PM -0500, Rick Macklem wrote:
Konstantin
Konstantin Belousov wrote:
On Tue, Dec 11, 2012 at 08:58:47PM -0500, Rick Macklem wrote:
Ok, I'll test r243598 and then r243599 and r243835, just to
see if it really is this.
I'll email when I have done this.
If you test only r243598, I am sure that you would experience
corruption
Konstantin Belousov wrote:
On Wed, Dec 12, 2012 at 10:01:39PM -0500, Rick Macklem wrote:
Konstantin Belousov wrote:
On Tue, Dec 11, 2012 at 08:58:47PM -0500, Rick Macklem wrote:
Ok, I'll test r243598 and then r243599 and r243835, just to
see if it really is this.
I'll email
Konstantin Belousov wrote:
On Wed, Dec 12, 2012 at 10:01:39PM -0500, Rick Macklem wrote:
Konstantin Belousov wrote:
On Tue, Dec 11, 2012 at 08:58:47PM -0500, Rick Macklem wrote:
Ok, I'll test r243598 and then r243599 and r243835, just to
see if it really is this.
I'll email
Just fyi, r243965 introduced a minor pola violation where the
nfsd daemon won't start for kernels built without options INET6.
The attached patch, which I will commit to head later to-day, fixes
the problem. (Or you can add options INET6 to your kernel config.)
Reported and tested by avg@.
rick
Oops, I did my usual brain fart again and forgot to attach the
patch. Here it is, rick
- Original Message -
Just fyi, r243965 introduced a minor pola violation where the
nfsd daemon won't start for kernels built without options INET6.
The attached patch, which I will commit to head
Hi,
Maybe someone familiar with the build environment can help
with this.
Someone reported via email that gssd.c no longer builds for
the combination of WITHOUT_KERBEROS and WITH_GSSAPI.
Now, the gssd is completely useless without kerberos, but
I need a way to fix the build for this case?
Can
David Wolfskill wrote:
On Sat, Dec 29, 2012 at 09:38:42AM -0800, Cy Schubert wrote:
Just udated to the latest current and amd hangs at boot. Ideas?
I don't see a problem @r244855. On my build machine, /usr/ports is a
symlink to a ports working copy that resides on a ReadyNAS:
bf1783 wrote:
Author: rmacklem
Date: Sat Dec 22 23:21:17 2012
New Revision: 244604
URL: http://svnweb.freebsd.org/changeset/base/244604
Log:
It was reported via email that some sshds create kerberos
credential cache files with names other than /tmp/krb5cc_uid.
The gssd daemon does
Garrett Cooper wrote:
On Sun, Dec 30, 2012 at 4:49 PM, Rick Macklem rmack...@uoguelph.ca
wrote:
bf1783 wrote:
Author: rmacklem
Date: Sat Dec 22 23:21:17 2012
New Revision: 244604
URL: http://svnweb.freebsd.org/changeset/base/244604
Log:
It was reported via email that some
Rick Macklem wrote:
Garrett Cooper wrote:
On Sun, Dec 30, 2012 at 4:49 PM, Rick Macklem rmack...@uoguelph.ca
wrote:
bf1783 wrote:
Author: rmacklem
Date: Sat Dec 22 23:21:17 2012
New Revision: 244604
URL: http://svnweb.freebsd.org/changeset/base/244604
Log
Rick Macklem wrote:
Rick Macklem wrote:
Garrett Cooper wrote:
On Sun, Dec 30, 2012 at 4:49 PM, Rick Macklem
rmack...@uoguelph.ca
wrote:
bf1783 wrote:
Author: rmacklem
Date: Sat Dec 22 23:21:17 2012
New Revision: 244604
URL: http://svnweb.freebsd.org/changeset/base
Cy Schubert wrote:
Just udated to the latest current and amd hangs at boot. Ideas?
It appears that r244678 broke the ip4 configuration of loopback for
some network interfaces.
I don't know, but it might explain why this is happening?
Also, if you happen to have a bxe(4) interface, it looks
Cy Schubert wrote:
Just udated to the latest current and amd hangs at boot. Ideas?
I think I spoke too soon w.r.t. the bxe(4) device and UDP checksums.
I thought I saw some email about UDP checksum offload for it being
broken but I can't locate the email, so I probably have this wrong.
Sorry
O. Hartmann wrote:
Since yesterday's update and buildworld on two FreeBSD 10.0-CURRENT
boxes, i realize a strange behaviour. I have one server exporting via
NFSv4 several ZFS volumes. The UID mapping went pretty well so far,
but
with a reboot of yesterday (after a buildworld), files are seen
Fabian Keil wrote:
Fleuriot Damien m...@my.gd wrote:
On Jan 4, 2013, at 4:19 PM, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
Am 01/04/13 15:45, schrieb Garrett Cooper:
On Fri, Jan 4, 2013 at 6:06 AM, Fleuriot Damien m...@my.gd wrote:
...
And this is under [global]
d wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 1/7/13 5:33 PM, Brandon Gooch wrote:
On Mon, Jan 7, 2013 at 6:09 PM, Xin Li delp...@delphij.net
mailto:delp...@delphij.net wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 01/07/13 16:02, Konstantin Belousov
Dimitry Andric wrote:
On 2011-11-23 19:26, Sean Bruno wrote:
On Wed, 2011-11-23 at 09:58 -0800, Rick Macklem wrote:
I don't know if Dimitry tried this, but you could also try the
nolockd option, so that byte range locking is done locally in
the client and avoids the NLM.
Good luck
John De wrote:
Hi Folks,
I have a 9-prerelease system where I've been testing nfs/zfs. The
system has been working quite well until moving the server to a
multihomed
configuration.
Given the following:
nfsd: master (nfsd)
nfsd: server (nfsd)
/usr/sbin/rpcbind -h 10.24.6.38 -h
Hi,
A recent NFS client crash:
http://glebius.int.ru/tmp/nfs_panic.jpg
appears to have happened because some field is
bogus when crfree() is called. I've asked Gleb
to disassemble crfree() for me, so I can try and
see exactly which field causes the crash, however...
Basically, the code:
John Baldwin wrote:
On Monday, December 19, 2011 8:21:45 pm Rick Macklem wrote:
Hi,
A recent NFS client crash:
http://glebius.int.ru/tmp/nfs_panic.jpg
appears to have happened because some field is
bogus when crfree() is called. I've asked Gleb
to disassemble crfree() for me, so I
First off, I had no idea which mailing list would be appropriate
for this, so apologies in advance if I chose the wrong one.
For NFSv4.1 pNFS, there are layout drivers in Linux that I would
like to reuse for the FreeBSD client. (Re-writing these drivers
from scratch would be a lot of work and
Way back in Nov 2010, this thread was related to a problem I
had, where an re(4) { 810xE PCIe 10/100baseTX, according to the
driver } interface dropped received packets, resulting in a
significant impact of NFS performance.
Well, it turns out that a recent (post r224506) commit seems to
have
Martin Cracauer wrote:
Stefan Bethke wrote on Wed, Jan 11, 2012 at 07:14:44PM +0100:
Am 11.01.2012 um 17:57 schrieb Martin Cracauer:
I'm sorry for the unspecific bug report but I thought a heads-up
is
better than none.
$ uname -a
FreeBSD wings.cons.org 10.0-CURRENT FreeBSD
Martin Cracauer wrote:
More findings.
Reminder, with the original report I found:
- files for no reason changing ownership and group to
root/owngroupname
- data corruption as in inserting binary junk obviously from ports
- data corruption as in malformed ascii text that might be a bug I
Martin Cracauer wrote:
More findings.
Reminder, with the original report I found:
- files for no reason changing ownership and group to
root/owngroupname
- data corruption as in inserting binary junk obviously from ports
- data corruption as in malformed ascii text that might be a bug I
O. Hartmann wrote:
Hello.
I still use the amd automounter, but I miss NFSv4 capabilities. Since
Linux seems to use a more deep in the kernel located facility, I'd
like
to ask whether FreeBSd has an alternative to the amd automounter with
NFSv4 capabilities. Sorry if I bother someone, I'm not
Hi,
r230516, which was just committed to head/current, will result in
a mount -u -o udp /path failing if the mount is using an
rsize/wsize/readdirsize of greater than 16384 (which will be the
case of a default sized TCP mount).
As such, specifying udp or mntudp options in the /etc/fstab
entry
John Baldwin wrote:
On Tuesday, January 31, 2012 12:21:07 pm Ulrich Spörlein wrote:
On Mon, 2012-01-30 at 09:36:45 -0500, John Baldwin wrote:
On Sunday, January 29, 2012 10:08:10 am Tijl Coosemans wrote:
On Wednesday 25 January 2012 17:29:22 John Baldwin wrote:
On Friday, January
Andrey Simonenko wrote:
On Mon, May 30, 2011 at 04:56:02PM -0400, Rick Macklem wrote:
Hi,
I have patches for the mountd, rpc.statd and rpc.lockd daemons
that are meant to keep them from failing when a dynamically
selected port# is not available for some combination of
udp,tcp X ipv4
Anton Shterenlikht wrote:
On Thu, May 10, 2012 at 09:51:22PM +0100, Anton Shterenlikht wrote:
On Thu, May 10, 2012 at 06:11:28PM +0400, Sergey Kandaurov wrote:
On 10 May 2012 14:30, Anton Shterenlikht me...@bristol.ac.uk
wrote:
On ia64 r235163:
root: /etc/rc.d/sysctl:
1 - 100 of 691 matches
Mail list logo
