[Gluster-users] help me, glusterfs 3.3 doen't support fopen-keep-cache?

[符永涛]

Hi Brian,
Thank you and you have helped me a lot!

2013/1/9, Brian Foster <bfoster at redhat.com>:
> On 01/09/2013 08:06 AM, 符永涛 wrote:
>> Hi Brian,
>> I check the review of c1fe8b7fd7 and find there's only one line code
>> change. I change accordingly in glusterfs3.3 and find page cache works
>> which boost performance for my usecase.
>
> Well c1fe8b7fd7 is a bit more than a one line change, but it is a
> relatively simple compatibility check just to ensure that your version
> of fuse supports the ability to invalidate cache mapping on demand. I
> didn't catch it when fopen-keep-cache first went in, so hence it was
> added after the fact. Glad to hear that this works for you, though!
>
>> 1 Besides make it a configurable mount option do I need to change any
>> other code?
>
> Nope, I think those two commits should be enough.
>
>> 2 Is there any side effect for doing this(FOPEN_KEEP_CACHE)?
>
> Just that open() operations will no longer unconditionally invalidate
> page cache mappings for files. The gluster md-cache translator will now
> become responsible for clearing the local cache. If it detects that the
> remote inode has changed since the version it has last cached (size or
> mtime, iirc), it will poke fuse to invalidate the local page cache. You
> should be able to test this mechanism by doing a 'touch <file>' on one
> of your bricks and verifying that the client now re-reads the file.
>
>> 3 I noticed this can be achied with only client side code change. Can
>> I only compile client side rpm and install it without any server side
>> upgrade(If this is true the upgrade impact and risk is much lower for
>> me since I'm running gluster in production)?
>>
>
> Correct, this is a client side only change. You should be able to deploy
> this on clients without modification to existing servers, provided
> things work as they are.
>
> Brian
>
>> Thank you very much.
>>
>> 2013/1/9, Brian Foster <bfoster at redhat.com>:
>>> On 01/08/2013 06:42 PM, yongtaofu wrote:
>>>> Hi brian
>>>> Thank you very much for your info.
>>>> I have already tried io-cache it helps a little but it can't compete
>>>> with
>>>> page cache.
>>>> BTW what's the effort if I want to back port fopen keep cache to 3.3?
>>>>
>>>
>>> No problem. I don't think it should be that difficult to pull back the
>>> keep cache patch to 3.3 if you wanted to, but feel free to ping me if
>>> you have trouble with it.
>>>
>>> Note that you probably want to include the following commit as well:
>>>
>>> c1fe8b7fd7 mount/fuse: check for fuse inval notify support when
>>> fopen-keep-cache enabled
>>>
>>> Brian
>>>
>>>> 发自我的 iPhone
>>>>
>>>> 在 2013-1-8，23:21，Brian Foster <bfoster at redhat.com> 写道：
>>>>
>>>>> On 01/08/2013 09:49 AM, 符永涛 wrote:
>>>>>> Dear gluster experts,
>>>>>>
>>>>>> I search through glusterfs 3.3 source tree and can't find any fuse
>>>>>> open option FOPEN_KEEP_CACHE related code. Does this mean that
>>>>>> glusterfs 3.3 doen't support fuse keep cache feature? However I did
>>>>>> find keep cache code in mainline. My question is:
>>>>>
>>>>> It appears that keep cache support is not included in the 3.3 release.
>>>>> You can build from the latest git repo to try it:
>>>>>
>>>>> 32ffb79f fuse/md-cache: add support for the 'fopen-keep-cache' mount
>>>>> option
>>>>>
>>>>>> 1 does glusterfs 3.3 support page cache?
>>>>>
>>>>> Page cache interaction is primarily a function of fuse. The current
>>>>> behavior is that writes are synchronous to the fuse filesystem, reads
>>>>> are potentially served from page cache, and file open operations
>>>>> invalidate the entire mapping for a file.
>>>>>
>>>>> The FOPEN_KEEP_CACHE fuse init option disables the latter behavior. In
>>>>> turn, gluster detects whether changes have occurred in the file
>>>>> remotely
>>>>> and nudges fuse to invalidate the file cache on-demand. There is also
>>>>> upstream fuse work in progress to support writeback cache behavior[1].
>>>>>
>>>>>> 2 if not what is the best practice to improve performance if a file
>>>>>> is
>>>>>> frequently accessed by read especially through random access fops.
>>>>>
>>>>> I would suggest to experiment with the tunables in the io-cache
>>>>> translator (xlators/performance/io-cache/src/io-cache.c), such as
>>>>> priority, cache-timeout and cache-size.
>>>>>
>>>>>> 3 does glusterfs 3.4 support page cache, if supported how to enable
>>>>>> it
>>>>>> through mount option?
>>>>>
>>>>> I would hope that it will at least include the keep cache support. Use
>>>>> the fopen-keep-cache mount option on latest gluster to try it out.
>>>>>
>>>>> Brian
>>>>>
>>>>> [1] -
>>>>> http://comments.gmane.org/gmane.comp.file-systems.fuse.devel/12266
>>>>>
>>>>>> Thank you very much.
>>>>>
>>>
>>>
>>
>>
>
>


-- 
符永涛