[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-cifs
Subject:    Re: sync/fsync issues on cifs drives
From:       Jeff Layton <jlayton () redhat ! com>
Date:       2012-03-30 20:03:17
Message-ID: 20120330160317.74e2570f () corrin ! poochiereds ! net
[Download RAW message or body]

On Fri, 30 Mar 2012 19:47:43 +0200
Federico Sauter <fsauter@innominate.com> wrote:

> Greetings,
> 
> 
> I am using an older kernel (2.6.27.57). I have made the following 
> observations:
> 
> Let S be a windows shared drive that maps to the local directory s (on 
> Windows) and let Q be another shared drive on the same machine, such 
> that Q maps to the local directory q and that s is the parent of q.
> 
> On my machine, I am mounting both S and Q separately, so that S is 
> mounted read-only and Q is mounted with read/write access. I have also 
> mounted S and Q using a different user for each as well as using the 
> same user for both. This does not seem to make a difference (even though 
> at least once it seemed to matter, but I could not reproduce it.)
> 
> Scenario 1:
> When I finish my operations, I write the results to Q and perform a 
> fsync system call on each one of the written files.
> 
> I have observed that, under Windows NT4 this leads to an error condition:
> 
>    fsync failed (11): Resource temporarily unavailable
> 
> Also showing LOG entries similar to:
> 
>    kernel:  CIFS VFS: Write2 ret -11, wrote 9370
>    kernel:  CIFS VFS: No response to cmd 46 mid 58582
> 
> Scenario 2:
> On a separated process that has nothing to do with the shared drives, a 
> sync system calls stalls for a very long time (possibly hours) before 
> returning.
> 
> I observed this behavior on NT4, I have reports of this happening with 
> Windows 2008 R2 Server, but I could *not* reproduce it with Windows XP 
> PRO nor with Windows Server 2003.
> 
> ---- END of observations ----
> 
> Question 1: why does this happen?
> 
> Question 2: Is this fixed in a newer kernel release?
> 
> Question 3: Is there any way to limit a sync call to a single filesystem?
> 
> ---- END of questions -----
> 
> I went ahead and looked at the kernel code, and the reason for this is 
> clearly that on fs/cifs/file.c:162
> 
>          if (n_iov) {
>              /* Search for a writable handle every time we call
>               * CIFSSMBWrite2.  We can't rely on the last handle
>               * we used to still be valid
>               */
>              open_file = find_writable_file(CIFS_I(mapping->host));
>              if (!open_file) {
>                  cERROR(1, ("No writable handles for inode"));
>                  rc = -EBADF;
>              } else {
>                  rc = CIFSSMBWrite2(xid, cifs_sb->tcon, 
> 
>                             open_file->netfid,
>                             bytes_to_write, offset,
>                             &bytes_written, iov, n_iov,
>                             CIFS_LONG_OP);
>                  atomic_dec(&open_file->wrtPending);
>                  if (rc || bytes_written < bytes_to_write) {
>                      cERROR(1, ("Write2 ret %d, wrote %d",
>                            rc, bytes_written));
>                      /* BB what if continued retry is
>                         requested via mount flags? */
>                      if (rc == -ENOSPC)
>                          set_bit(AS_ENOSPC, &mapping->flags);
>                      else
>                          set_bit(AS_EIO, &mapping->flags);
>                  } else {
>                      cifs_stats_bytes_written(cifs_sb->tcon,
>                                   bytes_written);
>                  }
>              }
> 
> The call to CIFSSMBWrite2 is never checked for an EAGAIN condition 
> (which is what is returned in those cases.) I have not experimented with 
> this yet (it may very well be that any number of retries end of in the 
> same situation,) but wanted to know whether modiying this would make 
> sense at all or not. I am fairly new to this portion of the kernel code.
> 

I think you might want to look at commit
941b853d779de3298e39f1eb4e252984464eaea8, though that has never really
had much testing in isolation from the conversion to async writes.

> Note: I am not suggesting making a patch out of that idea, I just want 
> to check whether the idea makes sense.
> 
> Thanks in advance for your kind support!
> 
> 
> Cheers,
> 

2.6.27 is really old at this point...

The short answer here is that the behavior in more recent kernels
(3.x-ish) should be much better. The cifs client now does asynchronous
writes which speeds things up tremendously. It's also more tolerant of
network problems during writeback.
-- 
Jeff Layton <jlayton@redhat.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]