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. >>>>> >>> >>> >> >> > > -- ???
