On Thu, 13 Feb 2014 18:29:45 +0100 Gionatan Danti <[email protected]> wrote:
> On 02/13/2014 12:37 PM, Jeff Layton wrote: > > > > Using cache=none sort of defeats the purpose. After all Gionatan said > > that he was doing this specifically to use fscache, and that won't work > > with cache=none. > > > > Surely my idea was to use FSCACHE to speed up remote access. Without it, > the entire discussion is pointless... > > > But, lets leave that aside for a moment and consider whether this could > > work at all. Assume we have samba set up re-share a cifs mount: > > > > Client sends an open to samba and requests an oplock. Samba then opens > > a file on the cifs mount, and does not request an oplock (because of > > cache=none). We then attempt to set a lease, which will fail because we > > don't have an oplock. Now you're no better off (and probably worse off) > > since you have zero caching going on and are having to bounce each > > request through an extra hop. > > > > So, suppose you disable "kernel oplocks" in samba in order to get samba > > to hand out L2 oplocks in this situation. Another client then comes > > along on the main (primary) server and changes a file. Samba is then > > not aware of that change and hilarity (aka data corruption) ensues. > > > > Are you of the same advice for low-frequency file changes (eg: office > files)? > > What about using NFS to export the Fileserver directory, mount it (via > mount.nfs) on the remote Linux box and then sharing via Samba? It is a > horrible frankenstein? > > > I just don't see how re-sharing a cifs mount is a good idea, unless you > > are absolutely certain that the data you're resharing won't ever > > change. If that's the case, then you're almost certainly better off > > keeping a local copy on the samba server and sharing that out. > > > > After many tests, I tend to agree. Using a Fedora 20 test machine with > fscache+cachefilesd as the remote Linux box, I had one kernel panic and > multiple failed file copies (with Windows complaing about a "bad > signature"). > > I also found this: https://bugzilla.redhat.com/show_bug.cgi?id=646224 > Maybe the CIFS FSCACHE is not really production-grade on latest distros > also? > BTW, if you're seeing panics or other problems then please do report them. As Suresh points out, the bug in that RHBZ should now be fixed. If you're still seeing a panic in that code then we do want to fix that. -- Jeff Layton <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
