Bug 853146

Comments from Csaba Henk on the breakdown of work:

I think to support a feature that comes with the latest
version of the FUSE protocol there is no other correct
way but implement all features up to that proto revision.
It would be hard to argue with, FUSE having adopted
a simple (theoretically two, practically one level)
linear numeric versioning scheme.

In general, let me categorize protocol updates as follows,
with respect to complexity of adjusting an implementation
to work with the update:

0: no action needed, as the update introduces a completely
    optional extension (aka. conservative extension)
1: a stub is to be provided / data layout is to be adjusted
2: the adjustment requires a proper implementation, which
    is easy
3: the adjustment requires a proper implementation, which
    is a significant development effort

We can enhance this simple four level system as follows:

- For the cases which require proper implementation (2, 3), allow
   not just these two values, but any number in between, according
   to the hardness of the implementation. (We could also use values
   beyond 3, to express situation where the implementation necessitates
   a heroic effort or there is a show stopper, but we don't need
   that here -- 3 is still meant to stand for a reasonable amount of work,
   and that covers our cases.)
- For the "stub suffices" cases (0, 1), let's have the p/q notation,
   where p is one of 0,1, and q is a value between 2 and 3. p is
   meant as above, q means the complexity of the (optional) proper
   implementation. We provide the "/q" part only if the feature
   in question is seen useful.

Let me annotate the 7.13+ FUSE proto changelog along these lines,
regarding the glusterfs side.

         7.14
0/3   :  - add splice support to fuse device
        0/2.5 : 7.15
          - add store notify
          - add retrieve notify
                 7.16
2     :  - add BATCH_FORGET request
0     :  - FUSE_IOCTL_UNRESTRICTED shall now return with array of 'struct
            fuse_ioctl_iovec' instead of ambiguous 'struct iovec'
0     :  - add FUSE_IOCTL_32BIT flag
                 7.17
1/2.5 :  - add FUSE_FLOCK_LOCKS and FUSE_RELEASE_FLOCK_UNLOCK
                 7.18
0     :  - add FUSE_IOCTL_DIR flag
0/2.5 :  - add FUSE_NOTIFY_DELETE
                 7.19
1/2   :  - add FUSE_FALLOCATE
                 7.20
0/2   :  - add FUSE_AUTO_INVAL_DATA

That is, to catch up to 7.20 with glusterfs, the only non-trivial thing to
do is to implement BATCH_FORGET, but that's not hard, and indeed,
quite useful (I think it would give some performance gain for small files).

   * * *

Other thing we need to know is the complexity of the proto upgrades
on kernel side. That's a different beast, because the implementations
for these upgrades are factually there, what we have to face with are
possible compatibility issues upon backporting them. For a cursory
glance, I did not seen anything that would stick out as a problematic
backport.

Regarding a non-cursory glance, I have a technical problem. Simply
I don't know what the RHEL kernel is, what backports it has already (eg.
I'm sure it has FUSE direct I/O support in, which is also a 7.13+
commit in upstream...). I'm quite noob to the RH engineering tools,
I'd be grateful for any pointer to useful resources or a primer.

Csaba

I think that we do need to keep in sync with upstream as best as we can in RHEL - this is critical for RHS and other user space file systems.