[Bugs] [Bug 1258905] Sharding - read/write performance improvements for VM workload

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1258905



--- Comment #2 from Paul Cuzner <pcuzner at redhat.com> ---
(In reply to Krutika Dhananjay from comment #0)
> Description of problem:
> 
> Paul Cuzner in his testing of sharding in hyperconvergence environment noted
> a 3x write latency and 2x read latency.
> One network operation that can be eliminated among the many things that
> shard translator does in every WRITEV and READV fop is the LOOKUP that is
> done on the zeroth shard to fetch the size and block_count xattr. Since VM
> workload is a single-writer use-case, and the client that wrote to a file is
> always the one that is going to read it, the size and block count xattr
> could be cached (and kept up-to-date) in the inode ctx of the main file,
> thereby saving the need for the (extra) LOOKUP every time.
> 
> The other place where network fops can be avoided is XATTROP, if/when there
> is a WRITEV that does not change the file size && block count,
> 
> Version-Release number of selected component (if applicable):
> 
> 
> How reproducible:
> 
> 
> Steps to Reproduce:
> 1.
> 2.
> 3.
> 
> Actual results:
> 
> 
> Expected results:
> 
> 
> Additional info:

This sounds great but I have to ask about shared vdisks - for example, RHEV
supports vdisk sharing across vm's. Typically this would mean that the disk is
only ever online to one vm at a time - but I wanted to make sure that this use
case is considered.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.