[Bugs] [Bug 1375959] Files not being opened with o_direct flag during random read operation ( Glusterfs 3.8.2)

bugzilla at redhat.com bugzilla at redhat.com
Thu Sep 15 13:28:42 UTC 2016


--- Comment #8 from Krutika Dhananjay <kdhananj at redhat.com> ---
(In reply to Krutika Dhananjay from comment #5)
> (In reply to Pranith Kumar K from comment #3)
> > Shekhar,
> >    You need the following two options for O_DIRECT to be handled properly:
> > 
> > 1) performance.strict-o-direct on
> > 2) network.remote-dio off
> > 
> > Pranith
> @Pranith - Part of the problem seems to be that the anonymous fds created by
> open-behind don't inherit the original open() flags. And when ob does wind
> reads and writes on these anon fds, posix winds up using the usual
> GF_ANON_FD_FLAGS (O_RDWR|O_LARGEFILE) value at the time of open() preceding
> the invoked fd operation (mostly read/write).
> FWIW, I did try the same test Shekhar ran on my test cluster and disabling
> open-behind in addition to the two already known o-direct options that you
> mentioned above, seemed to fix the issue of growing cache size as the test
> progresses (although it didn't have any effect as per Shekhar when he tried
> the same).
> I am yet to confirm the theory (and the presence/absence of O_DIRECT flag at
> the level of posix) through strace output of the bricks with and without
> open-behind. I will do the same tomorrow and update the bug.
> -Krutika

I stand corrected. *Even* with open-behind disabled, like Shekhar rightly said,
the issue still exists. I even disabled all perf xls and the problem still
persists. I found that open()s are being issued on gfid handles with
O_RDONLY|O_DIRECT flags in the bricks' strace output with all these xls
disabled. I still need to check if pread()s are being issued on the same file
descriptors though.

Still have some more strace analysis to do. Will update the bug again once the
issue is RC'd.


You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=cW2Za9FsyY&a=cc_unsubscribe

More information about the Bugs mailing list