<font><div><br></div></font><font><div><br></div></font><div><div style="color:#909090;font-family:Arial Narrow;font-size:12px">------------------</div><div><div style="color: rgb(0, 0, 0); font-family: Verdana; font-size: 14px; ">From a user's view,I have totally confused about how many kinks of caches are there in sheepdog and how many configurations can be used for cache...</div><div style="color: rgb(0, 0, 0); font-family: Verdana; font-size: 14px; "><br></div><div>We are exploring Ceph now, and it shows a better performance over sheepdog especially for sequential R/W and random write.I think the Sheepdog and Ceph share a similar internal design(i.e split the image to 4M object, some kinds of consistent-hash has been used).What we think most important is **journal disk** in storage node,Ceph's performance boost up to  3X when an extra 7200rpm sata disk was used for journal.Will sheepdog consider some similar mechanism?</div><div><br></div><div>Thanks. </div></div></div><div><includetail><div><br></div><div style="font-size: 12px;font-family: Arial Narrow;padding:2px 0 2px 0;">------------------ Original ------------------</div><div style="font-size: 12px;background:#efefef;padding:8px;"><div><b>From: </b> "MORITA Kazutaka"<morita.kazutaka@lab.ntt.co.jp>;</div><div><b>Date: </b> Mon, Oct 22, 2012 02:26 PM</div><div><b>To: </b> "Liu Yuan"<namei.unix@gmail.com>; <wbr></div><div><b>Cc: </b> "sheepdog"<sheepdog@lists.wpkg.org>; <wbr></div><div><b>Subject: </b> Re: [sheepdog] [PATCH 0/2] add cache options 'page' and 'unsafe'</div></div><div><br></div>At Mon, 22 Oct 2012 13:49:43 +0800,<br>Liu Yuan wrote:<br>> <br>> On 10/22/2012 01:33 PM, MORITA Kazutaka wrote:<br>> > I don't intend to avoid a flush completely with 'unsafe' mode.  The<br>> > difference between 'page' and 'unsafe' is that sheep doesn't call<br>> > syncfs even if a VM sends a flush request.<br>> > <br>> <br>> If disk is failed, I don't think buffered read/write will succeed<br>> because we will fail to open the fd. So your rationale about unsafe<br>> seems useless: no one will actually use it.<br><br>Actually we NTT would use it.  We have data centers which can supply<br>reliable power and we can regard that, if data is replicated to<br>multiple memories, the data is safe.  If disk is failed with 'unsafe'<br>mode, the node will be completely replaced with a new machine and<br>there is no risk of reading invalid data.<br><br>> <br>> I think 'page' and 'unsafe' can be merged into one mode, which indicates<br>> use page cache for storage backend IO.<br>> <br>> >> > <br>> >> > I think your patch set is going to finer-control the fd flags for page<br>> >> > cache. So I think we can control it via disk cache, like disk:pagecache.<br>> >> > <br>> >> > I am more concerned that the cache mode setting might look too<br>> >> > complicated to end users.<br>> > 'disk' means a disk cache of a local disk, so disk:pagecache looks<br>> > strange to me.  I think we should more descriptive names for caches.<br>> > There are two kinds of sheepdog caches; one uses a memory on storage<br>> > nodes and the other one uses a memory on gateway.  How about the<br>> > following?:<br>> > <br>> <br>> I think 'pagecache' is kind of straight forward and descriptive. Both<br>> 'page' and 'unsafe' will need additional explanation to what it really<br>> controls.<br>> <br>> why pagecache to disk is strange? I think most users of Linux will be<br>> familiar with page cache much more than other cache, for e.g, QEMU cache<br>> mode. If you are concerned that users might be confused with 'disk<br>> cache' and 'page cache', I'd suggest a new naming, 'gateway' for client<br>> side cache as you suggest, and 'backend' for cluster side cache.<br><br>A disk cache is controlled by a hardware (local disk) and a page cache<br>is by Linux.  I thought that using a two different things into one<br>name 'disk:pagecache' looks strange.<br><br>Anyway, using 'gateway'/'backend' and controlling fd flags with<br>backend options (e.g. backend:pagecache) look better to me.<br><br>Thanks,<br><br>Kazutaka<br><br>> <br>> I think direct exposure of which side of settings to take effect is<br>> better than umbrella all the settings inside.<br>> <br>> Thanks,<br>> Yuan<br>> <br>> -- <br>> sheepdog mailing list<br>> sheepdog@lists.wpkg.org<br>> http://lists.wpkg.org/mailman/listinfo/sheepdog<br>-- <br>sheepdog mailing list<br>sheepdog@lists.wpkg.org<br>http://lists.wpkg.org/mailman/listinfo/sheepdog<br></includetail></div>