Hi NFS List, chuck, trond:
I have a fun NFS problem with the recent 2.4 kernel NFS client. We have an
application that is failing when it tries to move then open a file in very
quick succession -- it fails because it can't find the file in the new
location.
Since we can't export our application out to the 'net, I've been doing
testing with fsx-linux, which also fails in the same scenario with what
looks like an attribute cache issue. The exact FSX error is
"Size error: expected 0x1803ca stat 0x1803ca seek 0x68bf4c".
This fails with the 3 kernels that I tested: 2.4.20, 2.4.21 and
2.4.22-pre9. When I add 'noac' to my mount flags on the client, the
problem goes away.
I've written this up on the following page, with links to the complete FSX
log, as well as complete kernel debug messages and the kernel .config
file.
http://www.phlinux.com/kernel/nfs-ac.html
I've been talking with Chuck Lever about this over the past few days, and
he suggested that I post here once I had good debug information. I'm happy
to run any other tests and/or capture other information if it's helpful.
Thanks!
-matt
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == Matt C <Matt> writes:
> Hi NFS List, chuck, trond: I have a fun NFS problem with the
> recent 2.4 kernel NFS client. We have an application that is
> failing when it tries to move then open a file in very quick
> succession -- it fails because it can't find the file in the
> new location.
It's a known issue. mmap() writes appear to be screwed up
w.r.t. truncate. I still don't have a proper solution for this
problem since it appears to be more of a VM bug than a NFS one.
Cheers,
Trond
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On 1 Aug 2003, Trond Myklebust wrote:
> >>>>> " " == Matt C <Matt> writes:
>
> > Hi NFS List, chuck, trond: I have a fun NFS problem with the
> > recent 2.4 kernel NFS client. We have an application that is
> > failing when it tries to move then open a file in very quick
> > succession -- it fails because it can't find the file in the
> > new location.
>
> It's a known issue. mmap() writes appear to be screwed up
> w.r.t. truncate. I still don't have a proper solution for this
> problem since it appears to be more of a VM bug than a NFS one.
>
Interesting. So the error condition you're describing would happen when we
mmap() a file descriptor, then munmap() it followed by an ftruncate()? I
guess I'm confused as to how this plays into the attribute cache (or if
that's a red herring) since adding the 'noac' flag seems to make this
problem go away.
Thanks for your help
-matt
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == Matt C <Matt> writes:
> Interesting. So the error condition you're describing would
> happen when we mmap() a file descriptor, then munmap() it
> followed by an ftruncate()? I guess I'm confused as to how this
> plays into the attribute cache (or if that's a red herring)
> since adding the 'noac' flag seems to make this problem go
> away.
noac might change the timings a bit so that writepage() sees that the
page it is about to write out lies beyond the current file length.
I would tend to distrust that as a permanent solution though...
Cheers,
Trond
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs