Re: Problem with Samba re-share of a CIFS mount

[Gionatan Danti <g.danti-N44kj/XGErOonA0d6jMUrA@public.gmane.org>]

On 02/13/2014 08:40 PM, Jeff Layton wrote:
>
> You'll have similar problems with NFS.
>
> You can't acquire leases on NFS either, so with kernel oplocks enabled
> on samba you won't ever get oplocks on there. If you turn them off (so
> that oplocks are tracked internally) you won't be aware of changes that
> occur outside of samba.

Ok, so it is the SMB protocol which is intrinsically unfriendly to 
persistent caches. Maybe it is for this very same reason that Microsoft 
suggest to use the "offline files" feature only where files change on 
one single side (eg: laptop).

> I don't recall whether Suresh ever fixed those bugs. cifs+fsc is
> certainly not widely used, and it wouldn't surprise me if it were still
> horribly buggy.
>
> fscache is somewhat at odds with the fundamental caching model of the
> cifs protocol. The whole point of fscache is to speed up access to
> frequently read files when a client starts up, and to reduce load on the
> server in these cases.
>
> For NFS, that works because we rely on looking at inode attributes to
> determine whether the file has changed (i.e. the mtime, size, NFSv4
> change attribute). So, with NFS we can reasonably tell whether a file
> has changed across a client remount.
>
> For CIFS, things are different. The protocol basically states that you
> should only cache file data if you hold an oplock, and you only get an
> oplock when you open a file. When you first bring up a client, you
> don't hold one, so you really should just toss out any data that you're
> caching...thereby making fscache sort of pointless.

What about not having an oplock but watch at file attributes (eg: last 
modified date)? I think cache=loose do this same thing. The man page say 
that Windows can be "lazy" to update file's attribute, but I think that 
we are speaking of some seconds at most. In scenarios with low 
cross-editing probability, this some-second window seems reasonable 
small. I am missing something?

> Now, there is some argument that you can use fsc and still follow the
> protocol by using it as "swap for pagecache". IOW, you could use it
> to cache a large amount of open file data than you have memory. I'm not
> aware of anyone having actually tested to see if that works however.
>

Mmm... this "swap for pagecache" will not survive reboot, right? Or, 
better stated, the cache _will_ survive, but by not having any oplock, 
the client will request the live data from the server, right?

Thank you.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti-N44kj/XGErOonA0d6jMUrA@public.gmane.org - info-N44kj/XGErOonA0d6jMUrA@public.gmane.org
GPG public key ID: FF5F32A8