Bug 853146 - fuse: sync driver with upstream
fuse: sync driver with upstream
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel (Show other bugs)
6.5
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Brian Foster
Red Hat Kernel QE team
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-30 11:19 EDT by Brian Foster
Modified: 2015-11-10 09:49 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-10 09:49:57 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brian Foster 2012-08-30 11:19:49 EDT
This is a place holder to track updating RHEL fuse from upstream. I don't know that we have specific feature requirements/requests quite yet, but the RHEL6 implementation is generally behind (which makes selective backports more difficult) and Red Hat Storage introduces a strong dependency on fuse. Setting a target for RHEL6.5 as this is the likely base for RHS2.1.
Comment 2 Brian Foster 2012-09-04 10:36:54 EDT
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
Comment 3 Ric Wheeler 2012-09-05 11:08:22 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.