Description of problem: Switching between multiple profiles wrongly update the barrier mount option for brick. Version-Release number of selected component (if applicable): appliance-base-1.7.1-1.el6rhs.noarch How reproducible: Steps to Reproduce: 1. Create the volume 2. Apply rhs-high-throughput and default tuned profile one after another multiple times $ tuned-adm profile rhs-high-throughput $ tuned-adm profile default $ tuned-adm profile rhs-high-throughput $ tuned-adm profile default Actual results: Brick mount option has multiple entries for barrier, nobarrier like following: /dev/mapper/test-brick on /brick/gluster type xfs (rw,noatime,inode64,barrier,nobarrier,barrier,nobarrier) Expected results: Brick mount option should just barrier entry according to the last applied profile. Additional info:
Does /proc/mounts should the same behavior? I think we should try to eliminate write barrier disabling from tuned profiles for RHS if we can establish that it doesn't hurt performance for MegaRAID at least. For small-file tests I could not detect any change in performance with barriers enabled, but I haven't tested large-file case yet. If we can do this, then we don't have to care about this bug anymore. Let's shoot for this in Corbett release.
Setting NEEDINFO till I get fix from Ben/Neependra
This should be fixed now because we no longer set barrier mount option in tuned profiles. Should be easy for QE to verify fix on RHS 3.0.
Thank you for submitting this issue for consideration in Red Hat Gluster Storage. The release for which you requested us to review, is now End of Life. Please See https://access.redhat.com/support/policy/updates/rhs/ If you can reproduce this bug against a currently maintained version of Red Hat Gluster Storage, please feel free to file a new report against the current release.