On 21 Jul 2016, at 5:10, Benjamin Coddington wrote:
On 21 Jul 2016, at 4:32, Benjamin Coddington wrote:
On 21 Jul 2016, at 4:22, hch@xxxxxxxxxxxxx wrote:
On Wed, Jul 20, 2016 at 11:03:06AM -0400, Benjamin Coddington wrote:
This debug output is identical for every cycle of the loop. Have
to
stop for the
day.. more tomorrow.
Ben
Duh??? It???s this patch: pNFS: Fix post-layoutget error handling
in
pnfs_update_layout()
We have to pass through fatal errors??? I???ll fix it.
That's indeed fixed it up, and generic/207 passes now. Thanks!
So I spoke too soon in my last mail, generic/207 still fails for me
with Trond's linux-next tree, although much later in the test now.
Does it include the changes that are supposed to fix the issue?
It should -- the v2 that fixed 207 for me is
56b38a1f7c781519eef09c1668a3c97ea911f86b, the first version was
e35c2a0b3cd062a8941d21511719391b64437427, I think. I'll test again
too.
Looks like we're back to the original problem - it fails with the
inode size is 4k less than expected.
The reason it worked for me was I had pnfs_ld debugging turned up
which slowed things down enough to somehow catch the right size.
Looks like the right size is returned in the CLOSE, but the inode's
not getting updated.
And the size is right in the last LAYOUTCOMMIT response, of course. Is
this the problem?
6024 static int decode_layoutcommit(struct xdr_stream *xdr,
...
6040 sizechanged = be32_to_cpup(p);
6041
6042 if (sizechanged) {
6043 /* throw away new size */
6044 p = xdr_inline_decode(xdr, 8);
Ben
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
