Filesystem in Userspace

Hi,
I tried to compile fuse with --enable-kernel-module (as I want to check
exporting of FUSE filesystem over NFS). I tried this with vanilla kernel 2.6.22.
It failed. I tried to find anything related using google but without success. I
wonder if anyone had similar problems and could help.

Thanks in advance. See output from make bellow (broke lines in some places):

Making all in kernel
gmake[1]: Entering directory `/tmp/fuse-2.7.0/kernel'
gmake -C /tmp/linux-build/ SUBDIRS=`pwd`  modules
gmake[2]: Entering directory `/tmp/linux-build'
gmake -C /usr/src/linux-2.6.22 O=/tmp/linux-build modules
  CC [M]  /tmp/fuse-2.7.0/kernel/file.o
In file included from /tmp/fuse-2.7.0/kernel/file.c:9:
/tmp/fuse-2.7.0/kernel/fuse_i.h:70:1: warning: "DEFINE_MUTEX" redefined
In file included from /usr/src/linux-2.6.22/include/linux/notifier.h:13,
                 from /usr/src/linux-2.6.22/include/linux/memory_hotplug.h:7,
                 from /usr/src/linux-2.6.22/include/linux/mmzone.h:466,
                 from /usr/src/linux-2.6.22/include/linux/gfp.h:4,
                 from /usr/src/linux-2.6.22/include/linux/slab.h:14,
                 from /usr/src/linux-2.6.22/include/linux/percpu.h:5,
                 from /usr/src/linux-2.6.22/include/linux/rcupdate.h:41,
                 from /usr/src/linux-2.6.22/include/linux/dcache.h:10,
                 from /usr/src/linux-2.6.22/include/linux/fs.h:275,
                 from /tmp/fuse-2.7.0/kernel/fuse_i.h:59,
                 from /tmp/fuse-2.7.0/kernel/file.c:9:
/usr/src/linux-2.6.22/include/linux/mutex.h:102:1: \
warning: this is the location
of the previous definition
In file included from /tmp/fuse-2.7.0/kernel/file.c:9:
/tmp/fuse-2.7.0/kernel/fuse_i.h:71:1: warning: "mutex_init" redefined
In file included from /usr/src/linux-2.6.22/include/linux/notifier.h:13,
                 from /usr/src/linux-2.6.22/include/linux/memory_hotplug.h:7,
                 from /usr/src/linux-2.6.22/include/linux/mmzone.h:466,
                 from /usr/src/linux-2.6.22/include/linux/gfp.h:4,
                 from /usr/src/linux-2.6.22/include/linux/slab.h:14,
                 from /usr/src/linux-2.6.22/include/linux/percpu.h:5,
                 from /usr/src/linux-2.6.22/include/linux/rcupdate.h:41,
                 from /usr/src/linux-2.6.22/include/linux/dcache.h:10,
                 from /usr/src/linux-2.6.22/include/linux/fs.h:275,
                 from /tmp/fuse-2.7.0/kernel/fuse_i.h:59,
                 from /tmp/fuse-2.7.0/kernel/file.c:9:
/usr/src/linux-2.6.22/include/linux/mutex.h:79:1: \
warning: this is the location
of the previous definition
In file included from /tmp/fuse-2.7.0/kernel/file.c:9:
/tmp/fuse-2.7.0/kernel/fuse_i.h:72:1: warning: "mutex_destroy" redefined
In file included from /usr/src/linux-2.6.22/include/linux/notifier.h:13,
                 from /usr/src/linux-2.6.22/include/linux/memory_hotplug.h:7,
                 from /usr/src/linux-2.6.22/include/linux/mmzone.h:466,
                 from /usr/src/linux-2.6.22/include/linux/gfp.h:4,
                 from /usr/src/linux-2.6.22/include/linux/slab.h:14,
                 from /usr/src/linux-2.6.22/include/linux/percpu.h:5,
                 from /usr/src/linux-2.6.22/include/linux/rcupdate.h:41,
                 from /usr/src/linux-2.6.22/include/linux/dcache.h:10,
                 from /usr/src/linux-2.6.22/include/linux/fs.h:275,
                 from /tmp/fuse-2.7.0/kernel/fuse_i.h:59,
                 from /tmp/fuse-2.7.0/kernel/file.c:9:
/usr/src/linux-2.6.22/include/linux/mutex.h:85:1: \
warning: this is the location
of the previous definition
In file included from /tmp/fuse-2.7.0/kernel/file.c:9:
/tmp/fuse-2.7.0/kernel/fuse_i.h:89:1: warning: "CONFIG_BLOCK" redefined
In file included from <command line>:1:
./include/linux/autoconf.h:969:1: \
warning: this is the location of the previous
definition
/tmp/fuse-2.7.0/kernel/file.c: In function ‘fuse_direct_write’:
/tmp/fuse-2.7.0/kernel/file.c:634: \
error: ‘struct inode’ has no member named ‘i_sem’
/tmp/fuse-2.7.0/kernel/file.c:638: \
error: ‘struct inode’ has no member named ‘i_sem’
gmake[5]: *** [/tmp/fuse-2.7.0/kernel/file.o] Error 1
gmake[4]: *** [_module_/tmp/fuse-2.7.0/kernel] Error 2
gmake[3]: *** [modules] Error 2
gmake[2]: *** [modules] Error 2
gmake[2]: Leaving directory `/tmp/linux-build'
gmake[1]: *** [all-spec] Error 2
gmake[1]: Leaving directory `/tmp/fuse-2.7.0/kernel'
gmake: *** [all-recursive] Error 1

On Wed, Aug 22, 2007 at 10:34:23AM +0200, Kim Saabye Pedersen wrote:
> Is it safe to assume that getattr is called before any other function?

Such questions are better to be asked on fuse-devel@. I CC my answer
there so that you will have the chance of being part of a discussion.

> I mean if my my file system calls getdir (eg. on executing ls path) I
> can see that getattr it called first.

If the kernel has the directory attributes cached, it doesn't need to
send a GETATTR to your fs daemon. However, your fs can enforce
non-caching (see the "-o entry_timeout" commandline option, which
is also tunable via the API).

Moreover, if you happen to use stateful directories (you make use of the
fuse_file_info argument of the readdir operation), then a directory
might be read in an already open state, in which case there is no need
to look it up, so there will be no getattr'ing. However, I doubt you
will want to use this feature, it's pretty much an esoteric one.

OTOH, what you should do is to use the readdir method and not getdir,
which is deprecated.

Anyway: it doesn't seem to be a clean design to rely on such
coincidences. If you uncover the problem which makes you want to rely on
the order of fs method calls, people might be able to give advice how
this can be tackled at in a more streamlined way.

Csaba

Can anyone tell me more about this error?

        Transport endpoint is not connected

Also, I put in some debugging fprintfs to a file(that gets flushed
constantly) in my destroy() function. After I get this error and
unmount, *sometimes* I dont see anything from my destroy() function.
Why doesnt it always get called?

Thanks

> From: css <css@...>

> So my question is, if this - a specialized linux-image for mounting
> fuse-filesystems on a virtual machine - is of use for anyone, and if
> anyone wants to help setting it up and making it more "comfortable"
> under windows, or if something like this already "officially" exists
> (i wouldnt be surprised)? If noone else has use of it or so I will
> stop working on it.

That was an incredibly well-timed posting (for me), because I got my fuse
filing system working a couple of days ago and was about to start *right now*
on implementing what you've just done (which I'ld mentioned in a posting
last week entitled "suggestion for quick & dirty windows implementation...").

If you wouldn't mind putting your image online, I'll be glad to try it out and
keep in touch with you offlist with comments, suggestions, additions etc.

The target audience for my project is mostly windows admins in small offices
who may not be very tech savvy, and it's important for what I'm doing to have
a slick and easy installation.  It sounds like you're interested in
the same sort
of thing, so I'ld be happy to work with you on it.

I was looking at either vmware or colinux myself, but qemu is just as good -
in some cases maybe better since unfortunately my university insisted on
installing SafeBoot (whole disk encryption) on my PC, and it breaks vmware
server which I've not been able to run for weeks; and CoLinux doesn't appear
to be compiled with fuse support in the kernel, though I found some posts a
few minutes ago that suggest perhaps it has been added in the current
development version.

By the way, one problem I found with Windows is that you can't mount SMB shares
over an NTFS directory - NTFS junction points don't support anything other than
other NTFS drives being mounted.  Apparently Vista does now have some
support for this but it's somewhat controversial (something to do with not being
able to re-export the root filing system with the mount points
intact).  But as long
as you don't mind your smb filing system being at the root of its
drive (or via a UNC),
it's OK.

I do recommend getting this to work with re-exporting over SMB though rather
than WebDAV.  WebDAV is not a real filing system.  I'm currently doing what
you're doing with smb, except that I'm using a physical machine rather than a
vmware instance.

A *very crude* draft of what I'm working on is available at Google
Docs if you're
interested:
http://docs.google.com/a/gtoal.com/Doc?docid=dgvk2s7q_10gp4g22&hl=en_US
 - it's more of a brain-dump than a proper paper (I wrote it in about
an hour last night)
so don't go quoting it anywhere until it's finished!

regards,


Graham

Hello list.

After looking at my logs on my filesystem implementet using FUSE (Python) I can
see that all other calls (e.g. mkdir, read, write, link etc.) are all preceeded
by a call to getattr.

So my question is: is it safe to assume that getattr is always called before the
actual filesystem call. Eg. is it safe to assume that a read call is always
preceeded by a getattr call?


I think it makes good sense at the filesystem has to get the stat of the given
path for instance in order to determine if the user issuing the call has the
sufficient rights to do so. But is there some corner cases where this assumption
is not valid?

Regards
Kim

Hi,
Is there any implementation of the chord protocol using the FUSE?

-Dharani