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 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?
Oh, and you can use the nolock mount option to avoid use
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 startup
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
From: Sam Fourman
On Tue, Jul 27, 2010 at 10:29 AM, krad kra...@googlemail.com 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
From: krad kra...@googlemail.com
To: freebsd-hack...@freebsd.org, FreeBSD Questions
freebsd-questions@freebsd.org
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
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
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
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
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,
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
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
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,
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 for
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
18 matches
Mail list logo
