On Tuesday 23 March 2010 7:03:06 pm Rick Macklem wrote:
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
On 03/22/10 19:53, Rick Macklem wrote:
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
On Monday 22 March 2010 7:53:23 pm Rick Macklem wrote:
That I have no idea on. Maybe Rick can chime in? I'm actually not sure why
we would want to treat a FHTOVP failure as anything but an ESTALE error in
the
NFS server to be honest.
As far as I know, only if the underlying file
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 Friday 19 March 2010 11:27:13 pm Rick Macklem wrote:
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
On 3/19/2010 11:27 PM, Rick Macklem wrote:
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
On 03/22/10 10:52, Steve Polyack wrote:
On 3/19/2010 11:27 PM, Rick Macklem wrote:
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
On Monday 22 March 2010 11:47:43 am Steve Polyack wrote:
On 03/22/10 10:52, Steve Polyack wrote:
On 3/19/2010 11:27 PM, Rick Macklem wrote:
On Fri, 19 Mar 2010, Steve Polyack wrote:
[good stuff snipped]
This makes sense. According to wireshark, the server is indeed
transmitting
On 03/22/10 12:00, John Baldwin wrote:
On Monday 22 March 2010 11:47:43 am Steve Polyack wrote:
On 03/22/10 10:52, Steve Polyack wrote:
On 3/19/2010 11:27 PM, Rick Macklem wrote:
On Fri, 19 Mar 2010, Steve Polyack wrote:
[good stuff snipped]
This makes sense.
On Monday 22 March 2010 12:44:04 pm Steve Polyack wrote:
On 03/22/10 12:00, John Baldwin wrote:
On Monday 22 March 2010 11:47:43 am Steve Polyack wrote:
On 03/22/10 10:52, Steve Polyack wrote:
On 3/19/2010 11:27 PM, Rick Macklem wrote:
On Fri, 19 Mar 2010, Steve
On 03/22/10 13:39, John Baldwin wrote:
On Monday 22 March 2010 12:44:04 pm Steve Polyack wrote:
On 03/22/10 12:00, John Baldwin wrote:
On Monday 22 March 2010 11:47:43 am Steve Polyack wrote:
On 03/22/10 10:52, Steve Polyack wrote:
On 3/19/2010 11:27 PM, Rick
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
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 weeks we have been
running into problems where one particular client will go into an
infinite loop
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 weeks we have been
running into problems
On 03/19/10 08:31, 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 03/19/10 09:23, Steve Polyack wrote:
On 03/19/10 08:31, 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
On 03/19/10 11:05, Steve Polyack wrote:
On 03/19/10 09:23, Steve Polyack wrote:
On 03/19/10 08:31, 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
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 3/19/2010 9:32 PM, Rick Macklem wrote:
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)
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
21 matches
Mail list logo
