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?
Thank you and regards.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@xxxxxxxxxx - info@xxxxxxxxxx
GPG public key ID: FF5F32A8
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
