<div dir="ltr"><div>Hi Sankarshan,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 16, 2020 at 9:15 AM sankarshan <<a href="mailto:sankarshan@kadalu.io">sankarshan@kadalu.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 15 May 2020 at 10:59, Hari Gowtham <<a href="mailto:hgowtham@redhat.com" target="_blank">hgowtham@redhat.com</a>> wrote:<br>
<br>
> ### User stories<br>
> * [Hari] users are hesitant to upgrade. A good number of issues in release-7 (crashes, flooding of logs, self heal) Need to look into this.<br>
> * [Sunil] Increase in inode size <a href="https://lists.gluster.org/pipermail/gluster-users/2020-May/038196.html" rel="noreferrer" target="_blank">https://lists.gluster.org/pipermail/gluster-users/2020-May/038196.html</a> Looks like it can have perf benefit.<br>
><br>
<br>
Is there work underway to ascertain if there are indeed any<br>
performance related benefits? What are the kind of tests which would<br>
be appropriate?<br></blockquote><div><br></div><div>Rinku has done some tests downstream to validate that the change doesn't cause any performance regression. Initial results don't show any regression at all and it even provides a significant benefit for 'ls -l' and 'unlink' workloads. I'm not sure yet why this happens as the xattrs for these tests should already fit inside 512 bytes inodes, so no significant differences were expected.</div><div><br></div><div>The real benefit would be with volumes that use at least geo-replication or quotas. In this case the xattrs may not fit inside the 512 bytes inodes, so 1024 bytes inodes will reduce the number of disk requests when xattr data is not cached (and it's not always cached, even if the inode is in cache). This testing is pending.</div><div><br></div><div>From the functional point of view, we also need to test that bigger inodes don't cause weird inode allocation problems when available space is small. XFS allocates inodes in contiguous chunks in disk, so it could happen that even though there's enough space in disk (apparently), an inode cannot be allocated due to fragmentation. Given that the inode size is bigger, the required chunk will also be bigger, which could make this problem worse. We should try to fill a volume with small files (with fsync pre file and without it) and see if we get ENOSPC errors much before it's expected.</div><div><br></div><div>Any help validating our results or doing the remaining tests would be appreciated.</div><div><br></div><div>Regards,</div><div><br></div><div>Xavi</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
> * Any release updates?<br>
> * 6.9 is done and announced<br>
> * [Sunil]can we take this in for release-8: <a href="https://review.gluster.org/#/c/glusterfs/+/24396/" rel="noreferrer" target="_blank">https://review.gluster.org/#/c/glusterfs/+/24396/</a><br>
> * [Rinku]Yes, we need to ask the patch owners to port this to release8 post merging it to master. Till the time we tag release8 this is possible post this it will be difficult, after which we can put it in release8.1<br>
> * [Csaba] This is necessary as well <a href="https://review.gluster.org/#/c/glusterfs/+/24415/" rel="noreferrer" target="_blank">https://review.gluster.org/#/c/glusterfs/+/24415/</a><br>
> * [Rinku] We need release notes to be reviewed and merged release8 is blocked due to this. <a href="https://review.gluster.org/#/c/glusterfs/+/24372/" rel="noreferrer" target="_blank">https://review.gluster.org/#/c/glusterfs/+/24372/</a><br>
<br>
Have the small set of questions on the notes been addressed? Also, do<br>
we have plans to move this workflow over to GitHub issues? In other<br>
words, how long are we planning to continue to work with dual systems?<br>
<br>
<br>
> ### RoundTable<br>
> * [Sunil] Do we support cento8 and gluster?<br>
> * [sankarshan] Please highlight the concerns on the mailing list. The developers who do the manual testing can review and provide their assessment on where the project stands<br>
> * We do have packages, how are we testing it?<br>
> * [Sunil] Centos8 regression is having issues and are not being used for regression testing.<br>
> * [Hari] For packages, Shwetha and Sheetal are manually testing the bits with centos8. Basics works fine. But this testing isn't enough<br>
> * send out a mail to sort this out<br>
<br>
I am guessing that this was on Sunil to send out the note to the list.<br>
Will be looking forward to that.<br>
<br>
> * [Amar] Kadalu 0.7 release based on GlusterFS 7.5 has been recently released (Release Blog: <a href="https://kadalu.io/blog/kadalu-storage-0.7" rel="noreferrer" target="_blank">https://kadalu.io/blog/kadalu-storage-0.7</a>)<br>
> * [Rinku] How to test<br>
> * [Aravinda] <a href="https://kadalu.io/docs/k8s-storage/latest/quick-start" rel="noreferrer" target="_blank">https://kadalu.io/docs/k8s-storage/latest/quick-start</a><br>
<br>
<br>
<br>
<br>
-- <br>
<a href="mailto:sankarshan@kadalu.io" target="_blank">sankarshan@kadalu.io</a> | TZ: UTC+0530 | +91 99606 03294<br>
<a href="http://kadalu.io" rel="noreferrer" target="_blank">kadalu.io</a> : Making it easy to provision storage in k8s!<br>
_______________________________________________<br>
<br>
Community Meeting Calendar:<br>
<br>
Schedule -<br>
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC<br>
Bridge: <a href="https://bluejeans.com/441850968" rel="noreferrer" target="_blank">https://bluejeans.com/441850968</a><br>
<br>
<br>
<br>
<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-devel</a><br>
<br>
</blockquote></div></div>