Re: CIFS data coherency problem

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

 



On Thu, Sep 9, 2010 at 1:18 PM, Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote:
> 2010/9/8 Jeff Layton <jlayton@xxxxxxxxx>:
>> On Wed, 8 Sep 2010 10:49:13 +0400
>>
>> What sort of server were you working with here?
>
> Samba 3.4, Samba 4, Windows XP.
>
>>
>> At the very least, we should consider a "strict" caching model like you
>> describe as an option. If it has a large performance impact then we may
>> want to allow people to use the existing caching model as well. OTOH,
>> maintaining multiple caching models may be too cumbersome to support.
>
> Yes, It brings complexity. As for performance: how can we talk about
> performance if we have invalid data? In this case when we can't use
> any serious application for business on CIFS file system (because of
> wrong data coherency) why do we need such a performance? I think we at
> first should keep all the data up to date and then think about
> performance and other not so important things.
>
>>
>> If you're saying however that the spec says this, then it would
>> also be helpful to point out the place in the spec that outlines this
>> so we can go back and read over that part.
>
> 3.2.4.18 from [MS-CIFS].pdf states when a client should use a cache
> for reading, writing or locking. You can also look at
> http://go.microsoft.com/fwlink/?LinkID=140636 for more information
> about oplock semantic. In every case I didn't noticed any information
> for using cache if we don't have an oplock. If you have such an
> information it'll be very interesting to see it.

Note that metadata caching is common for most network file systems
(not unique to cifs or nfs) - and is usually done on a timer.

NFSv3 data caching is unsafe - no guarantees data makes it to server
until sync or close.  Generally if a file has not changed between
close and open - seems reasonable to keep the cached copy.   If we
have two opens of the same file from different clients we won't be
caching anyway.

In SMB2 we will be doing batch oplock.


-- 
Thanks,

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