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@xxxxxxxxxxxxxxxxxx>
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
