Re: Regression tests for CIFS client

[Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On Fri, 10 Aug 2012 10:57:35 +0530
Suresh Jayaraman <sjayaraman-IBi9RG/b67k@public.gmane.org> wrote:

> On 08/09/2012 08:33 PM, Jeff Layton wrote:
> > On Thu, 09 Aug 2012 20:07:56 +0530
> > Suresh Jayaraman <sjayaraman-IBi9RG/b67k@public.gmane.org> wrote:
> >>>
> >>> With all of the recent changes to the read/write code, I think we can
> >>> reasonably do O_DIRECT now. Just make sure that you don't request an
> >>> oplock on open and ensure that you're not using cache=loose codepaths.
> >>>
> >> Hmm, I'm not sure yet what is going on wrong.. I disabled oplocks by doing
> >>
> >>    echo N > /sys/module/cifs/parameters/enable_oplocks
> >>
> >> (Is there a way for an application to not request oplocks?)
> >> and mounted with cache=strict and ran the directIO test alone.
> >>
> >> strace output (snip)
> >> --------------
> >> stat("/mnt/cifstests", 0x7fff317e68f0)  = -1 ENOENT (No such file or
> >> directory)
> >> mkdir("cifstests", 0755)                = 0
> >> chdir("cifstests")                      = 0
> >> open("testfile", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
> >> fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> >> close(3)                                = 0
> >> open("testfile", O_RDONLY|O_DIRECT)     = -1 EINVAL (Invalid argument)
> >> write(1, "[Errno 22] Invalid argument: 'te"..., 40) = 40
> >>
> >> But I see from dmesg oplocks are being granted.
> >>
> > Sorry, I might not have been clear. I meant that in principle, we could
> > probably fix the cifs client to do O_DIRECT properly now that we have
> > the strictcache code. It doesn't do that currently, of course...
> 
> Ah, ok. What does it take to fix the cifs client? I could take a look.
> Are there pointers to discussion threads on this topic?
> 

No real discussion on this so far, just something I had considered when
Pavel did the strictcache code. cache=strict (and cache=none for that
matter) basically does dio already when it doesn't have an oplock. When
cache=strict is in force you can just make an O_DIRECT open not request
one at all and you're basically done.

There are some things to be worked out:

1) what to do about cache=loose? Should an O_DIRECT open make it use a
different codepath?

2) what to do about mmap? Currently we fall back to buffered I/O
codepaths for mmap even when we don't have an oplock. Should we do
anything different if someone tries to mmap an O_DIRECT file?

One of the complicating factors is that we have different sets of
file_operations for different cache= values. If you unify those, it
might make it easier to do all of this.

-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>