[Gluster-devel] Fuse on newer kernels

[Reinis Rozitis]

Hey,
as fuse 2.7.3 / 2.7.4 doesnt build on kernels 2.6.25/.26/.27 wanted to ask 
if it is valid to use fuse-2.8.0-pre1?  I mean has anyone tested it?


Basically with the 2.7.3 patched version and also 2.7.4 clean version you 
get something like this:

/data/install/fuse-2.7.3glfs10/kernel/dir.c: In function ‘fuse_permission’:
/data/install/fuse-2.7.3glfs10/kernel/dir.c:860: error: ‘LOOKUP_ACCESS’ 
undeclared (first use in this function)
/data/install/fuse-2.7.3glfs10/kernel/dir.c:860: error: (Each undeclared 
identifier is reported only once
/data/install/fuse-2.7.3glfs10/kernel/dir.c:860: error: for each function it 
appears in.)
/data/install/fuse-2.7.3glfs10/kernel/dir.c: At top level:
/data/install/fuse-2.7.3glfs10/kernel/dir.c:1329: warning: initialization 
from incompatible pointer type
/data/install/fuse-2.7.3glfs10/kernel/dir.c:1348: warning: initialization 
from incompatible pointer type
make[4]: *** [/data/install/fuse-2.7.3glfs10/kernel/dir.o] Error 1
make[3]: *** [_module_/data/install/fuse-2.7.3glfs10/kernel] Error 2
make[2]: *** [sub-make] Error 2


I have tracked down in 2.6.26 Changelog something like this:


commit a110343f0d6d41f68b7cf8c00b57a3172c67f816
Author: Al Viro <viro at zeniv.linux.org.uk>
Date:   Thu Jul 17 09:19:08 2008 -0400

    [PATCH] fix MAY_CHDIR/MAY_ACCESS/LOOKUP_ACCESS mess

    * MAY_CHDIR is redundant - it's an equivalent of MAY_ACCESS
    * MAY_ACCESS on fuse should affect only the last step of pathname 
resolution
    * fchdir() and chroot() should pass MAY_ACCESS, for the same reason why
      chdir() needs that.
    * now that we pass MAY_ACCESS explicitly in all cases, LOOKUP_ACCESS can 
be
      removed; it has no business being in nameidata.

Where it seems that LOOKUP_ACCESS has been removed...




On the other hand I could compile 2.7.4 with the performance patch ( 
fuse-2.7.3glfs10.diff) and when replacing in kernel/dir.c:


if (nd && (nd->flags & (LOOKUP_ACCESS | LOOKUP_CHDIR))) {

to

if (nd && (nd->flags & MAY_ACCESS)) {


Not sure if its the only place to change but for now couldnt get work on 
2.6.27-rc5-git9-15-default (x86_64) .. eg it starts but get in some nasty 
state with an error:

Process glusterfs (pid: 24996, threadinfo ffff8802175ac000, task 
ffff8802118245c0)
Stack:  0000000000000000 0000000000041200 ffff8802175ada58 ffffffffa02fb6be
 ffff8802175adac8 ffffffff802bbc77 0000000000000000 0000000000000000
 ffff880221ce8580 0000000000000000 ffff880221ce8580 0000001000000000
Call Trace:
 [<ffffffffa02fb6be>] fuse_inode_init_once+0x11/0x13 [fuse]
 [<ffffffff802bbc77>] cache_grow+0x1de/0x298
 [<ffffffff802bbf0e>] cache_alloc_refill+0x1dd/0x22e
 [<ffffffff802bc6c3>] kmem_cache_alloc+0xfc/0x156
 [<ffffffffa02fb641>] fuse_alloc_inode+0x1f/0x71 [fuse]
 [<ffffffff802d799f>] alloc_inode+0x21/0x1ea
 [<ffffffff802d870d>] iget5_locked+0x62/0x1cd
 [<ffffffffa02fb994>] fuse_iget+0x48/0x1aa [fuse]
 [<ffffffffa02fbefc>] fuse_fill_super+0x406/0x61b [fuse]
 [<ffffffff802c5696>] get_sb_nodev+0x5c/0x9c
 [<ffffffffa02fb164>] fuse_get_sb+0x1b/0x1d [fuse]
 [<ffffffff802c53f3>] vfs_kern_mount+0xa2/0x131
 [<ffffffff802c54e9>] do_kern_mount+0x4c/0xe7
 [<ffffffff802dc55a>] do_new_mount+0x64/0x96
 [<ffffffff802dd492>] do_mount+0x20c/0x23b
 [<ffffffff802dd54f>] sys_mount+0x8e/0xd3
 [<ffffffff8020c57a>] system_call_fastpath+0x16/0x1b
 [<00007fde6318082a>] 0x7fde6318082a



I will try to test it back on 2.6.26...  If not the only working option now 
stays the 2.6.24 kernel...


But any thoughts on all this mess?


rr