2010/11/29 Suresh Jayaraman <sjayaraman@xxxxxxx>:
> On 11/29/2010 05:07 PM, Jeff Layton wrote:
>> On Mon, 29 Nov 2010 13:58:05 +0300
>> Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote:
>>
>>> 2010/11/28 Jeff Layton <jlayton@xxxxxxxxxx>:
>>>> On Sun, 28 Nov 2010 06:36:04 -0500
>>>> Jeff Layton <jlayton@xxxxxxxxxx> wrote:
>>>>
>>>>> On Sun, 28 Nov 2010 11:12:49 +0300
>>>>> Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote:
>>>>>
>>>>>> On strict cache mode if we don't have Exclusive oplock we write a data to
>>>>>> the server through cifs_user_write. Then if we Level II oplock store it in
>>>>>> the cache, otherwise - invalidate inode pages affected by this writing.
>>>>>>
>>>>>> Signed-off-by: Pavel Shilovsky <piastryyy@xxxxxxxxx>
>>>>>> ---
>>>>>> ïfs/cifs/cifsfs.c | ï 40 ++++++++++++++++++++++++++++++++++++----
>>>>>> ï1 files changed, 36 insertions(+), 4 deletions(-)
>>>>>>
>>>>>> diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
>>>>>> index bbb5294..901c82b 100644
>>>>>> --- a/fs/cifs/cifsfs.c
>>>>>> +++ b/fs/cifs/cifsfs.c
>>>>>> @@ -598,12 +598,44 @@ static ssize_t cifs_file_aio_read(struct kiocb *iocb, const struct iovec *iov,
>>>>>> ïstatic ssize_t cifs_file_aio_write(struct kiocb *iocb, const struct iovec *iov,
>>>>>> ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ïunsigned long nr_segs, loff_t pos)
>>>>>> ï{
>>>>>> - ï struct inode *inode = iocb->ki_filp->f_path.dentry->d_inode;
>>>>>> + ï struct inode *inode;
>>>>>> + ï struct cifs_sb_info *cifs_sb;
>>>>>> ï ï ssize_t written;
>>>>>>
>>>>>> - ï written = generic_file_aio_write(iocb, iov, nr_segs, pos);
>>>>>> - ï if (!CIFS_I(inode)->clientCanCacheAll)
>>>>>> - ï ï ï ï ï filemap_fdatawrite(inode->i_mapping);
>>>>>> + ï inode = iocb->ki_filp->f_path.dentry->d_inode;
>>>>>> +
>>>>>> + ï if (CIFS_I(inode)->clientCanCacheAll)
>>>>>> + ï ï ï ï ï return generic_file_aio_write(iocb, iov, nr_segs, pos);
>>>>>> +
>>>>>> + ï cifs_sb = CIFS_SB(iocb->ki_filp->f_path.dentry->d_sb);
>>>>>> +
>>>>>> + ï if ((cifs_sb->mnt_cifs_flags & CIFS_MOUNT_STRICT_IO) == 0) {
>>>>>> + ï ï ï ï ï int rc;
>>>>>> +
>>>>>> + ï ï ï ï ï written = generic_file_aio_write(iocb, iov, nr_segs, pos);
>>>>>> +
>>>>>> + ï ï ï ï ï rc = filemap_fdatawrite(inode->i_mapping);
>>>>>> + ï ï ï ï ï if (rc)
>>>>>> + ï ï ï ï ï ï ï ï ï cFYI(1, "cifs_file_aio_write: %d rc on %p inode",
>>>>>> + ï ï ï ï ï ï ï ï ï ï ï ïrc, inode);
>>>>>> + ï ï ï ï ï return written;
>>>>>> + ï }
>>>>>> +
>>>>>> + ï /* in strict cache mode we need to write the data to the server exactly
>>>>>> + ï ï ïfrom the pos to pos+len-1 rather than flush all affected pages
>>>>>> + ï ï ïbecause it may cause a error with mandatory locks on these pages but
>>>>>> + ï ï ïnot on the region from pos to ppos+len-1 */
>>>>>
>>>>> ï ï ï Again, please fix the comment style. Here: ^^^^
>>>>>
>>>>>> + ï written = cifs_user_write(iocb->ki_filp, iov->iov_base,
>>>>>> + ï ï ï ï ï ï ï ï ï ï ï ï ï ï iov->iov_len, &pos);
>>>>>> +
>>>>>> + ï iocb->ki_pos = pos;
>>>>>> +
>>>>>> + ï /* if we were successful - invalidate inode pages the write affected */
>>>>>> + ï if (written > 0)
>>>>>> + ï ï ï ï ï invalidate_mapping_pages(inode->i_mapping,
>>>>>> + ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï (pos-written) >> PAGE_CACHE_SHIFT,
>>>>>> + ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï (pos-1) >> PAGE_CACHE_SHIFT);
>>>>>> +
>>>>>> ï ï return written;
>>>>>> ï}
>>>>>>
>>>>>
>>>>> May god have mercy on anyone who tries to mix strictcache and mmap.
>>>>>
>>>>> Reviewed-by: Jeff Layton <jlayton@xxxxxxxxxx>
>>>>
>>>> (cc'ing Suresh so he can comment)
>>>>
>>>> Actually...I'm going to withdraw my Reviewed-by tag here for now. This
>>>> bare invalidate_mapping_pages doesn't deal with fscache.
>>>>
>>>> I think I need to understand what's intended when someone specifies
>>>> strictcache and fsc before I can ack this. The simple answer would be
>>>> that they are mutually exclusive, but if that's the case then the patch
>>>> that adds the mount option needs to deal with that appropriately.
>>>
>>>
>>> I don't think they can live together. I think we should do smth like a
>>> following in mount options parsing:
>>>
>>> ...
>>> if (opt == fscache) {
>>> Â Âvol->fscahe = 1;
>>> Â Âvol->strictcache = 0;
>>> }
>>> ...
>>> if (opt == strictcache) {
>>> Â vol->strictcache = 1;
>>> Â vol->fscache = 0;
>>> }
>>>
>>> So, if user specify both only the last will affect the client
>>> behavior. Also we should add this information into cifs manpage.
>>> Thoughts?
>>>
>>
>> That would one way to deal with it.
>>
>> On the other hand though...fscache allows you to keep more data cached
>> than you have RAM. This could be useful in a strictcache situation as
>> well. Consider the case of an application on a client that has a lot of
>> large files open for read. The server may grant oplocks on all of them.
>> fscache would allow for fewer round trips to the server in such a case.
>>
>> So, another way to deal with it would be to simply invalidate the
>> fscache whenever you'd invalidate the in-ram cache. I'm not sure what
>> to do for the cifs_file_aio_write case where you're invalidating just a
>> small range however.
>>
>
> Yes, we seem to have those two options while the later has the advantage
> that Jeff mentioned. I think we could do the later without much of a
> problme. We just need to retire the cookies and get new ones
> (relinquishing with retire set to 1) i.e. by calling
> cifs_fscache_reset_inode_cookie(). FS-Cache does not provide data
> invalidation by itself. For the cifs_file_aio_write case too we could
> set invalid_mapping and get fresh cookies.
>
>
What's about mmap and fsync patch? How do you think they mix with fscache?
--
Best regards,
Pavel Shilovsky.
--
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
