> I just setup an nfs mount between two servers ...
>
> ServerA, nfsd on 192.168.1.8
> ServerB, nfs client on 192.168.1.7
>
> I have a jail, ServerC, running on 192.168.1.7 ... most operations
> appear
> to work, but it looks like 'special files' of a sort aren't working,
> for
> when I try and s
> > I just setup an nfs mount between two servers ...
> >
> > ServerA, nfsd on 192.168.1.8
> > ServerB, nfs client on 192.168.1.7
> >
> > I have a jail, ServerC, running on 192.168.1.7 ... most operations
> > appear
> > to work, but it looks like 'special files' of a sort aren't working,
> > for
>
> On Fri, 1 Apr 2011, Rick Macklem wrote:
>
> >> Since rpc.lockd and rpc.statd expect to be able to do IP broadcast
> >> (same goes for rpcbind), I suspect that might be a problem w.r.t.
> >> jails, although I know nothing about how jails work?
> >>
> Since today's source (FreeBSD 9.0-CURRENT/amd64 (source is: Revision:
> 221060) update I get the follwoing error while building the kernel
> (options NFSD/options NFSCL instead of options NFSSERVER/options
> NFSCLIENT):
>
> cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=native
>
> > Since today's source (FreeBSD 9.0-CURRENT/amd64 (source is:
> > Revision:
> > 221060) update I get the follwoing error while building the kernel
> > (options NFSD/options NFSCL instead of options NFSSERVER/options
> > NFSCLIENT):
> >
> > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing
>
On Wed, 16 Jan 2008, Robert Watson wrote:
[good stuff snipped]
Right now we maintain a relatively stable VM/VFS KPI withing a major release
(i.e, FreeBSD 6.0 -> 6.1 -> 6.2 -> 6.3), but see fairly significant changes
between major releases (5.x -> 6.x -> 7.x, etc). I expect to see further
On Mon, 8 Feb 2010, O. Hartmann wrote:
Mounting the filessystem via
mount_newnfs host:/path /path
Oh, and you should set:
sysctl vfs.newnfs.locallocks_enable=0
in the server, since I haven't fixed the local locking yet. (This implies
that apps/daemons running locally on the server
On Mon, 8 Feb 2010, O. Hartmann wrote:
Mounting the filessystem via
mount_newnfs host:/path /path
works fine, but not
mount -t nfs4 host:/path /path.
The mount command can be either:
mount -t nfs -o nfsv4 host:/path /path
or
mount -t newnfs -o nfsv4 host:/path /path
(The above was what
On Mon, 8 Feb 2010, O. Hartmann wrote:
Oh, and you should set:
sysctl vfs.newnfs.locallocks_enable=0
in the server, since I haven't fixed the local locking yet. (This implies
that apps/daemons running locally on the server won't see byte range
locks performed by NFSv4 clients.) However, b
On Mon, 8 Feb 2010, O. Hartmann wrote:
So I guess the above one is the more 'transparent' one with respect to the
future, when NFSv4 gets mature and its way as matured into the kernel?
Yea, I'd only use "mount -t newnfs" if for some reason you want to
test/use the experimental client fo
On Tue, 9 Feb 2010, O. Hartmann wrote:
Well, I guess I havn't uderstood everything of NFSv4. The 'concept' of the
'root' is new to me, maybe there are some deeper explanation of the purpose?
Are there supposed to be more than one 'root' enries or only one?
Only to specify different securi
On Fri, 19 Mar 2010, John Baldwin wrote:
On Friday 19 March 2010 7:34:23 am Steve Polyack wrote:
Hi, we use a FreeBSD 8-STABLE (from shortly after release) system as an
NFS server to provide user home directories which get mounted across a
few machines (all 6.3-RELEASE). For the past few wee
On Fri, 19 Mar 2010, Steve Polyack wrote:
To anyone who is interested: I did some poking around with DTrace, which led
me to the nfsiod client code.
In src/sys/nfsclient/nfs_nfsiod.c:
} else {
if (bp->b_iocmd == BIO_READ)
(void) nfs_doio(bp->b_vp, bp, bp->b_
On Fri, 19 Mar 2010, Steve Polyack wrote:
[good stuff snipped]
This makes sense. According to wireshark, the server is indeed transmitting
"Status: NFS3ERR_IO (5)". Perhaps this should be STALE instead; it sounds
more correct than marking it a general IO error. Also, the NFS server is
s
On Mon, 22 Mar 2010, John Baldwin wrote:
It looks like it also returns ESTALE when the inode is invalid (<
ROOTINO || > max inodes?) - would an unlinked file in FFS referenced at
a later time report an invalid inode?
I'm no ufs guy, but the only way I can think of is if the file system
on t
On Tue, 23 Mar 2010, John Baldwin wrote:
Ah, I had read that patch as being a temporary testing hack. If you think
that would be a good approach in general that would be ok with me.
Well, it kinda was. I wasn't betting on it fixing the problem, but since
it does...
I think just mapping VF
> From: "krad"
> To: freebsd-hack...@freebsd.org, "FreeBSD Questions"
>
> Sent: Tuesday, July 27, 2010 11:29:20 AM
> Subject: possible NFS lockups
> I have a production mail system with an nfs backend. Every now and
> again we
> see the nfs die on a particular head end. However it doesn't die
>
> From: "Sam Fourman
> On Tue, Jul 27, 2010 at 10:29 AM, krad wrote:
> > I have a production mail system with an nfs backend. Every now and
> > again we
> > see the nfs die on a particular head end. However it doesn't die
> > across all
> > the nodes. This suggests to me there isnt an issue with t
18 matches
Mail list logo