<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 6, 2017 at 4:30 AM, Raghavendra Gowdappa <span dir="ltr"><<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
Storage/posix does syscalls on backend filesystem holding inode->lock. This is bad as it is a lock global to the inode and can cause unnecessary contention with unrelated translators doing unrelated operations (like inode_ctx_get etc). I've discussed one such issue in [2]. A quick git grep on "inode->lock" in storage/posix gave following results:<br>
<br>
* posix_writev -<br>
GLUSTERFS_WRITE_IS_APPEND - looks like used by arbiter/afr.<br>
GLUSTERFS_WRITE_UPDATE_ATOMIC - looks like used by shard<br>
* posix_fd_ctx_get - resolves gfid handle (which can involve multiple readlinks and lstats) in inode->lock. Though the cost is only once when fd-ctx is freshly created.<br>
* code that maintains pgfid xattrs - executed in various dentry modification fops like mkdir, create, mknod, unlink, rename, link etc<br>
* code that uses GET_LINK_COUNT - looks like used by shard and EC. Note that this code is executed during rename/unlink.<br>
* posix_create_link_if_gfid_<wbr>exists - looks like used by afr entry selfheal<br>
* posix_(f)xattrop - various xlators like afr, marker during different fops.<br>
<br>
The question here is can we've synchronization using a lock visible only to storage/posix so that contention is localized (like [1])?<br>
<br></blockquote><div><br></div><div>I think the answer depends on the degree of isolation required across threads operating on the same inode. If the operations being done within "inode->lock" do not cause any side effects elsewhere in the xlator stack, we should be able to replace inode->lock with a more local lock. At the outset it looks like we should be able to synchronize using a smaller lock for most cases. A more careful analysis is needed to determine if there are scenarios where inode->lock helps.</div><div><br></div><div>Regards,</div><div>Vijay</div></div></div></div>