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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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@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




[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux