fuse: introduce pre-test micro-framework, check for execve-over-direct-IO

The presence of some potential FUSE features in the actual kernel-side FUSE
implementation we run on is not always straightforward. More precisely, it is
straightforward only if there is a dedicated feature flag or protocol revision
number. In the other cases we are left to clumsy and platform specific hacks
which wire in 3rd-party software revision numbers into our source... at least,
if we insist on sticking to (the otherwise venerable) KISS principle.

However, here we go for another route, loosely inspired by the way autotools
provide an abstraction layer for our build system over the gory details of
platform specific build environments.

At start time, we use a preliminary set of FUSE operations which overlay the
standard ones such that apart from the "usual stuff", they also present some
synthetic files to the FUSE client (kernel). Then we spawn some test programs
which perform the needed tests on these synthetic files to evaulate the FUSE
implementation in terms of the features in question. According to the result
of the test programs, we set the respective parameters of the fuse xlator;
when the testing phase is over, the FUSE operation set is replaced by the
standard one.

As of now, we use this approach to test whether execve(2) works with
direct I/O. If yes, and if glusterfs is used with --enable-direct-io-mode,
then we let direct I/O for files opened for reading; if no, then we restrict
direct I/O only to writing files.

Signed-off-by: Csaba Henk <csaba@gluster.com>
Signed-off-by: Vijay Bellur <vijay@dev.gluster.com>

BUG: 801 (Direct io-mode support and related changes in caching translators.)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=801

0 files changed, 0 insertions, 0 deletions