fuse-devel — FUSE developement related discussion

[fuse-devel] Fuse on embedded 2.4.22

[Jorgen L. <lu...@lu...>]

I'm sure this has been touched upon before, but I thought I would give 
it an attempt myself.  I have an embedded system running something old:

Linux uclibc 2.4.22-em86xx-uc0-sigma #1 �� 6�� 27 18:28:41 HKT 2007 
armv4l unkno 
       wn

I have tried 1.4, 2.0b, and 2.5.3 versions, and since they all have 
similar "undefined references", I focused my attention on the version 
with the highest number. Hoping for better compatibility later.

Initially, it went like this:

inode.c:598: unknown field `alloc_inode' specified in initializer
inode.c:598: warning: initialization from incompatible pointer type
inode.c:599: unknown field `destroy_inode' specified in initializer
inode.c:599: warning: initialization from incompatible pointer type

Seems my 2.4.22 kernel still have the old way to get inodes, I should be 
able to steal the inode_alloc code from 2.0b and use it. but for now, I 
have just commented out these two lines to see how far I can go.


Attempting to load it:

uclibc[/tmp]# insmod fuse.o
Using fuse.o
insmod: unresolved symbol page_cache_release
insmod: unresolved symbol get_user_pages
insmod: unresolved symbol grab_cache_page


I came across a kernel patch that suggested "grab_cache_page" can be 
replaced with

   //struct page *page = grab_cache_page(inode->i_mapping, index);

   struct page *page = find_or_create_page(inode->i_mapping, index, 
GFP_NOFS);


page_cache_release I have not found an alternate for, but if it is just 
to release the page, I have simply made it an empty function. The theory 
being that it should work, but leak memory like crazy.

Similarly, get_user_pages has no alternate, but appears to only be used 
in direct_io style mount. I can live without that, but also has a 
reference in dev.c which I am unsure about.

Anyway, this leaves us with:

uclibc[/tmp]# insmod fuse-25.o
Using fuse-25.o
uclibc[/tmp]# lsmod
Module                  Size  Used by    Tainted: P
fuse-25                25664   0 (unused)

uclibc[/tmp]# ./hello-25 /mnt/USB2 -d -s &
25157


And nothing... in fact, it seems to be that the "hello" mount program 
does not get to the part where it talks to the kernel. It uses fork, and 
pthreads (and it seems you can not disable the use of pthreads, foo!). I 
took out daemon(), and replace fork with vfork but has made no difference.

I also suspect that it (tries to) create /dev/ entries for me? As the 
filesystem is read-only, I would have to create the /dev entries by 
hand. Are the major/minor numbers well known?

If someone could take a minute or so to send me some suggestions that 
would be appreciated. Going to a newer kernel just is not an option, as 
I have no idea how the current kernel was built, and would have a high 
chance of bricking the unit.

Lund



-- 
Jorgen Lundman       | <lu...@lu...>
Unix Administrator   | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo    | +81 (0)90-5578-8500          (cell)
Japan                | +81 (0)3 -3375-1767          (home)

Re: [fuse-devel] RFC: New interface for real (block deviced based) FS

[Goswin v. B. <bre...@in...>]

"Paul Alfille" <pau...@gm...> writes:

> On 9/6/07, Goswin von Brederlow <[[bre...@in...]]>
> wrote:
>
>           So when fuse needs to read something you pass it an array of
>      fuse_vec
>      describing the location of the data on the real device(s) costing
>      you
>      24 bytes per continious chunk instead of having to shuffle 128K from
>      kernel to user to kernel space. The fuse kernel module would then
>      construct an iovec from the reply and read directly into the
>      destination pages.
>      
>      When fuse needs to write something again you pass it an array of
>      fuse_vec describing the location of the data on the real
>      device(s). This time where it needs to write to. The fuse kernel
>      module would then construct an iovec from the reply and the pages
>      with
>      data and write to the device.
>      
>
>
> How do you handle the notification of data lifetimes? Could your data buffers
> be reclaimed before
> the client actually uses the data?
> Paul Alfille

On write the fuse module gets handed some user space memory, it asks
the fuse library for a fuse_vec, constructs an iovec, runs the write
function, frees the iovec and returns to the caller which can do
whatever it likes with the buffer.

On read the fuse module gets handed some empty user space memory, it
asks the fuse library for a fuse_vec, constructs an iovec, runs the
read function, frees the iovec and returns to the caller which can do
whatever it likes with the buffer.

Lifetime of the user space memory is as long as the system call takes
and fuse has nothing to do with allocating and freeing it.

MfG
        Goswin

Re: [fuse-devel] porting libfuse 2.7.0 to Solaris.. continued

[Mark P. <Mark.Phalan@Sun.COM>]

On Wed, 2007-09-05 at 23:00 +0200, Miklos Szeredi wrote:
> > > Hi,
> > > 
> > > I've been working on getting libfuse 2.7.0 working on OpenSolaris. I've
> > ...
> > 
> > I've got another question about libfuse and mounting. It works currently
> > in OpenSolaris via a delicate dance between the library and the kernel
> > module..
...
> mount() sends FUSE_INIT, but doesn't wait for the reply.  FUSE_INIT
> cannot fail.  While no reply is received, all other requests are held
> back.
> 

Ah, that makes sense. I'll look into modifying our fuse module to do
something similar.


> > I guess one solution would be to exchange the version information etc
> > before doing the mount. i.e. perhaps via an ioctl.
> 
> Yeah, I thought about that when designing the interface, but just
> having a pure read/write interface without any ioctl magic has
> advantages.  Like it is easy to forward over a pipe or some other

Agreed. I'm not too crazy about ioctl magic myself.

> interface.  This property is actually used by "mountlo", a loopback
> mount utility based on fuse and user-mode-linux.

I'm not familiar with "mountlo". I'll take a look.

Thanks for the help!

-Mark

Re: [fuse-devel] RFC: New interface for real (block deviced based) FS

[Paul A. <pau...@gm...>]

On 9/6/07, Goswin von Brederlow <bre...@in...>
wrote:
>
> So when fuse needs to read something you pass it an array of fuse_vec
> describing the location of the data on the real device(s) costing you
> 24 bytes per continious chunk instead of having to shuffle 128K from
> kernel to user to kernel space. The fuse kernel module would then
> construct an iovec from the reply and read directly into the
> destination pages.
>
> When fuse needs to write something again you pass it an array of
> fuse_vec describing the location of the data on the real
> device(s). This time where it needs to write to. The fuse kernel
> module would then construct an iovec from the reply and the pages with
> data and write to the device.
>

How do you handle the notification of data lifetimes? Could your data
buffers be reclaimed before
the client actually uses the data?

Paul Alfille

Re: [fuse-devel] read more than 128kB

[Jan E. <je...@co...>]

On Sep 6 2007 13:39, Miklos Szeredi wrote:
>> 
>> I'm not sure why fuse_read() without my own memcpy() is about as slow as 
>> the non-FUSE program with the same memcpy(). Perhaps FUSE does another 
>> memcpy() on its own, in addition to the one in the fuse_read() (?)
>
>It does.  With buffered read, it does 2 extra copies.  With
>"-odirect_io" it does 1 extra copy, which is unavoidable.

Could not it at least use splice() somewhere?


>> >> So is there any way (no custom kernels thanks!) to get better performance
>> >> out of FUSE? Modify FUSE code? And increase the maximum read size from
>> >> measly 128kB to a few megabytes somehow?

And BTW, my read() function gets the typical 4096 passed for the "size"
argument, can this be raised?

[fuse-devel] RFC: New interface for real (block deviced based) FS

[Goswin v. B. <bre...@in...>]

Hi,

while playing around with fuse I came to wonder how much time fuse
looses just due to copying around data between kernel and user space
all the time. When using a read block device as storage medium for
your fs there is usualy no need to look at the user data in any way
and shuffeling to the user space is completly wasted.

So here is some rough idea for a new interface that prefents this:

A new data structure (fuse_vec) is needed to pass along information of
where the data is (to be) stored instead of the actual data.

struct fuse_vec {
       int fd;          /* File descriptor containing the data */
       off_t base;      /* Offset where the data starts */
       size_t size;     /* Amount of continous data */
}


A new low level function is needed to reply to requests with an
fuse_vec instead of a buffer.

/**
 * Reply with IO vector
 *
 * Possible requests:
 *   read, write
 *
 * @param req request handle
 * @param vec array of fuse IO vectors describing the data location
 * @param len number of segments in vec
 * @return zero for success, -errno for failure to send reply
 */
int fuse_reply_vec(fuse_req_t req, const fuse_vec *vec, size_t len);


The read call can remain as is but needs to accept a fuse_vec reply as
alternative to a buffer and the write call needs to be modified to not
pass a buffer (null) when fuse_vec based operations are active (or a
new write_vec call that doesn't get a buf argument at all).

void (*write_vec) (fuse_req_t req, fuse_ino_t ino,
                   size_t size, off_t off, struct fuse_file_info *fi);


So when fuse needs to read something you pass it an array of fuse_vec
describing the location of the data on the real device(s) costing you
24 bytes per continious chunk instead of having to shuffle 128K from
kernel to user to kernel space. The fuse kernel module would then
construct an iovec from the reply and read directly into the
destination pages.

When fuse needs to write something again you pass it an array of
fuse_vec describing the location of the data on the real
device(s). This time where it needs to write to. The fuse kernel
module would then construct an iovec from the reply and the pages with
data and write to the device.


I think this could give a substantial improvement. What I'm unclear of
is how to manage the 'int fd' in the fuse_vec. That has to be the file
descriptor of the fuse user-space thread and the kernel module has to
access that somehow.

What do you think?

MfG
        Goswin

Re: [fuse-devel] read more than 128kB

[Miklos S. <mi...@sz...>]

> is there any reasonable way to increase the read size in FUSE from the 128kB limit?
> 
> Right now FUSE or the kernel split all >128kB user read()'s into several 
> <=128kB read calls, this severely reduces performance. There's a data 
> acquisition DAQ card I'm reading from.
> 
> 
> With a simple non-FUSE test program that does >4 MB reads through the DAQ 
> cards own kernel module API, I get around 1500 Mbit/s throughput.
> 
> But with the FUSEs chunked 128kB reads, performance is around 30 Mbit/s. 
> That's lousy.
> 
> I then added some buffering/caching code to my FUSE read(). It does one 
> blocking DAQ card read of 16MB and then memcpy()s data out to the user on 
> each next read() call. Performance now is ~400 Mbit/s. But significant 
> time is lost in the memcpy() - which would be unnecessary if FUSE could 
> pass larger than 128kB data out to the user.

Hmm, what is the performance if you just comment out the memcpy()?

> So is there any way (no custom kernels thanks!) to get better performance 
> out of FUSE? Modify FUSE code? And increase the maximum read size from 
> measly 128kB to a few megabytes somehow?

It should be possible if you increase FUSE_MAX_PAGES_PER_REQ from 32
to 1024 in fuse/fuse_i.h in the kernel tree, and give
"-omax_read=4194304" mount option.

I'm curious how much that helps.

Miklos

Re: [fuse-devel] read more than 128kB

[Miklos S. <mi...@sz...>]

> >> I then added some buffering/caching code to my FUSE read(). It does one
> >> blocking DAQ card read of 16MB and then memcpy()s data out to the user on
> >> each next read() call. Performance now is ~400 Mbit/s. But significant
> >> time is lost in the memcpy() - which would be unnecessary if FUSE could
> >> pass larger than 128kB data out to the user.
> >
> > Hmm, what is the performance if you just comment out the memcpy()?
> 
> For a bunch of different 440MB files, trying
> $ /usr/bin/time cat /mnt/fuse/testfileN > /dev/null
> and then the same with a 'dd bs=256k' or similar, too:
> 
> Without any memcpy()
> 
>    0.29user 1.03system 0:05.69elapsed
> 
> and with the memcpy()
> 
>    0.11user 0.68system 0:08.77elapsed
> 
> With the non-FUSE test program the time is around 0:02.54elapsed. Adding 
> a 128kB memcpy() loop into there slows it down to near 6 seconds.
> 
> I'm not sure why fuse_read() without my own memcpy() is about as slow as 
> the non-FUSE program with the same memcpy(). Perhaps FUSE does another 
> memcpy() on its own, in addition to the one in the fuse_read() (?)

It does.  With buffered read, it does 2 extra copies.  With
"-odirect_io" it does 1 extra copy, which is unavoidable.

> (Btw there's some heavy latency in the DAQ card API Read() call, so it is 
> essential to always read big chunks of data...)
> 
> 
> >> So is there any way (no custom kernels thanks!) to get better performance
> >> out of FUSE? Modify FUSE code? And increase the maximum read size from
> >> measly 128kB to a few megabytes somehow?
> >
> > It should be possible if you increase FUSE_MAX_PAGES_PER_REQ from 32
> > to 1024 in fuse/fuse_i.h in the kernel tree, and give
> > "-omax_read=4194304" mount option.
> >
> > I'm curious how much that helps.
> 
> Thanks! Tried it, but unfortunately no improvement, still gives
> 
>    0.12user 0.85system 0:08.87elapsed
> 
> Checking what the size passed to fuse read() is, it is actually 4096 
> bytes, on the target machine.
> 
> The 128kB read size I got from my devel machine (didn't try 
> FUSE_MAX_PAGES_PER_REQ there).
> 
> 
> Btw I'm using fuse 2.5.3, because the target system has to run kernel 2.4 

Ah.  The real problem is 2.4, which doesn't have readahead usable by fuse.

There's an option "-olarge_read" but it has its own problems, so I
don't recommend using that.

You should rather try "-odirect_io", which will bypass the page cache
(and mmap won't work), but it will also do one less memory copy, so
that might help.

Not having readahead can have other problems, you can't have
overlapping data processing and data acquisition, unless you do some
multi threading or multi processing in your app.

But basically using direct_io for streaming read should give you the
best possible performance in fuse.

Miklos

Re: [fuse-devel] read more than 128kB

[Jan W. <jw...@ku...>]

>> I'm not sure why fuse_read() without my own memcpy() is about as slow as
>> the non-FUSE program with the same memcpy(). Perhaps FUSE does another
>> memcpy() on its own, in addition to the one in the fuse_read() (?)
>
> It does.  With buffered read, it does 2 extra copies.  With
> "-odirect_io" it does 1 extra copy, which is unavoidable.

Ah, ok! That explains the "slowness".

Well, the target PC is quite antiquated (~5 years), on a modern PC the 
time spent in memcpy() would probably be negligible for the total 
throughput.


>> Btw I'm using fuse 2.5.3, because the target system has to run kernel 2.4
>
> Ah.  The real problem is 2.4, which doesn't have readahead usable by fuse.
>
> There's an option "-olarge_read" but it has its own problems, so I
> don't recommend using that.
>
> You should rather try "-odirect_io", which will bypass the page cache
> (and mmap won't work), but it will also do one less memory copy, so
> that might help.

Excellent - many thanks for the tip! Indeed the 440MB data copying time 
that before was
   0.11user 0.68system 0:08.77elapsed
is now
   0.00user 0.02system 0:04.10elapsed
so it went from 400 Mbps to 660 Mbps, not bad!

I'm not sure if -olarge_read together with -odirect_io is a recipe for 
trouble, but with both options things become a little faster still, closer 
around 800 Mbps:
   0.02user 0.08system 0:03.99elapsed

Going into the right direction towards ~1.5 Gbps now... :-))


> Not having readahead can have other problems, you can't have
> overlapping data processing and data acquisition, unless you do some
> multi threading or multi processing in your app.

Could be a concern, but in the current kind use this should not be a big 
problem, reading is sequential (90% of the time) and the data is copied 
out steadily by one user app. The readahead I don't care so much about, as 
I had to implement that myself anyway inside my fuse_read() such that the 
high latency actual DAQ Read() is called only once in >=128 fuse_read() 
sequential read calls.

Many thanks for your help!
The mount option suggestions were really good! :-)

  - Jan

Re: [fuse-devel] read more than 128kB

[Jan W. <jw...@ku...>]

On Thu, 6 Sep 2007, Miklos Szeredi wrote:
>> I then added some buffering/caching code to my FUSE read(). It does one
>> blocking DAQ card read of 16MB and then memcpy()s data out to the user on
>> each next read() call. Performance now is ~400 Mbit/s. But significant
>> time is lost in the memcpy() - which would be unnecessary if FUSE could
>> pass larger than 128kB data out to the user.
>
> Hmm, what is the performance if you just comment out the memcpy()?

For a bunch of different 440MB files, trying
$ /usr/bin/time cat /mnt/fuse/testfileN > /dev/null
and then the same with a 'dd bs=256k' or similar, too:

Without any memcpy()

   0.29user 1.03system 0:05.69elapsed

and with the memcpy()

   0.11user 0.68system 0:08.77elapsed

With the non-FUSE test program the time is around 0:02.54elapsed. Adding 
a 128kB memcpy() loop into there slows it down to near 6 seconds.

I'm not sure why fuse_read() without my own memcpy() is about as slow as 
the non-FUSE program with the same memcpy(). Perhaps FUSE does another 
memcpy() on its own, in addition to the one in the fuse_read() (?)

(Btw there's some heavy latency in the DAQ card API Read() call, so it is 
essential to always read big chunks of data...)


>> So is there any way (no custom kernels thanks!) to get better performance
>> out of FUSE? Modify FUSE code? And increase the maximum read size from
>> measly 128kB to a few megabytes somehow?
>
> It should be possible if you increase FUSE_MAX_PAGES_PER_REQ from 32
> to 1024 in fuse/fuse_i.h in the kernel tree, and give
> "-omax_read=4194304" mount option.
>
> I'm curious how much that helps.

Thanks! Tried it, but unfortunately no improvement, still gives

   0.12user 0.85system 0:08.87elapsed

Checking what the size passed to fuse read() is, it is actually 4096 
bytes, on the target machine.

The 128kB read size I got from my devel machine (didn't try 
FUSE_MAX_PAGES_PER_REQ there).


Btw I'm using fuse 2.5.3, because the target system has to run kernel 2.4 
(DAQ card driver..), and fuse 2.6 'make' said it does not support module 
compile for these ancient kernels.

Perhaps fuse 2.5.3 does not really support the max_read mount option?

Any ideas where does the 4kB limit in fuse 2.5.3 come from?

Thanks!
  - Jan

[fuse-devel] read more than 128kB

[Jan W. <jw...@ku...>]

Hi,

is there any reasonable way to increase the read size in FUSE from the 128kB limit?

Right now FUSE or the kernel split all >128kB user read()'s into several 
<=128kB read calls, this severely reduces performance. There's a data 
acquisition DAQ card I'm reading from.


With a simple non-FUSE test program that does >4 MB reads through the DAQ 
cards own kernel module API, I get around 1500 Mbit/s throughput.

But with the FUSEs chunked 128kB reads, performance is around 30 Mbit/s. 
That's lousy.

I then added some buffering/caching code to my FUSE read(). It does one 
blocking DAQ card read of 16MB and then memcpy()s data out to the user on 
each next read() call. Performance now is ~400 Mbit/s. But significant 
time is lost in the memcpy() - which would be unnecessary if FUSE could 
pass larger than 128kB data out to the user.


So is there any way (no custom kernels thanks!) to get better performance 
out of FUSE? Modify FUSE code? And increase the maximum read size from 
measly 128kB to a few megabytes somehow?

  - Jan

Re: [fuse-devel] porting libfuse 2.7.0 to Solaris.. continued

[Miklos S. <mi...@sz...>]

> > Hi,
> > 
> > I've been working on getting libfuse 2.7.0 working on OpenSolaris. I've
> ...
> 
> I've got another question about libfuse and mounting. It works currently
> in OpenSolaris via a delicate dance between the library and the kernel
> module..
> 
> 1. mount() is called, during which a FUSE_INIT message is sent to the
> library via /dev/fuse. It blocks until libfuse responds.
> 
> 2. libfuse reads the FUSE_INIT message from the kernel module and they
> exchange version numbers etc. If everything is ok, mount() returns and
> the filesystem is mounted.
> 
> libfuse had to be modified to fork before doing the mount as mount()
> will block until libfuse responds to the FUSE_INIT request - i.e.
> libfuse needs at least two processes, one to do the mount() call and the
> second to respond to the FUSE_INIT request before the mount() call
> returns.
> 
> This greatly complicates things.
> 
> How does the Linux kernel module work? Does it avoid the FUSE_INIT
> messaging during mount()? Does mount() return successfully only to later
> fail if FUSE_INIT fails?

mount() sends FUSE_INIT, but doesn't wait for the reply.  FUSE_INIT
cannot fail.  While no reply is received, all other requests are held
back.

> I guess one solution would be to exchange the version information etc
> before doing the mount. i.e. perhaps via an ioctl.

Yeah, I thought about that when designing the interface, but just
having a pure read/write interface without any ioctl magic has
advantages.  Like it is easy to forward over a pipe or some other
interface.  This property is actually used by "mountlo", a loopback
mount utility based on fuse and user-mode-linux.

Miklos

Re: [fuse-devel] write vs getattr/lookup file size update race in FUSE kernel module [test+proposed fix]

[Miklos S. <mi...@sz...>]

> > So the only important thing is to not update the _cached_ attributes
> > in that case.
> 
> Right. And finally solution looks correctly to me.

Cool, thanks for looking at it.

> Do you expect to release fuse containing these changes any soon, or
> there are some issues delaying it?

I'll start coding it up as soon as I get a chance.  Which is basically
the week after next week.

Miklos

Re: [fuse-devel] do_forget() leak a fuse_req

[Miklos S. <mi...@sz...>]

> running into some memory leak, I found than do_forget() need
> a fuse_reply_none(req); patch attached.

Thanks, patch applied and committed.

I really appreciate the ChangeLog entry as well.

Miklos

Re: [fuse-devel] porting libfuse 2.7.0 to Solaris.. continued

[Mark P. <Mark.Phalan@Sun.COM>]

On Fri, 2007-08-31 at 12:34 +0200, Mark Phalan wrote:
> Hi,
> 
> I've been working on getting libfuse 2.7.0 working on OpenSolaris. I've
...

I've got another question about libfuse and mounting. It works currently
in OpenSolaris via a delicate dance between the library and the kernel
module..

1. mount() is called, during which a FUSE_INIT message is sent to the
library via /dev/fuse. It blocks until libfuse responds.

2. libfuse reads the FUSE_INIT message from the kernel module and they
exchange version numbers etc. If everything is ok, mount() returns and
the filesystem is mounted.

libfuse had to be modified to fork before doing the mount as mount()
will block until libfuse responds to the FUSE_INIT request - i.e.
libfuse needs at least two processes, one to do the mount() call and the
second to respond to the FUSE_INIT request before the mount() call
returns.

This greatly complicates things.

How does the Linux kernel module work? Does it avoid the FUSE_INIT
messaging during mount()? Does mount() return successfully only to later
fail if FUSE_INIT fails?
I guess one solution would be to exchange the version information etc
before doing the mount. i.e. perhaps via an ioctl.


Cheers,
-Mark

Re: [fuse-devel] write vs getattr/lookup file size update race in FUSE kernel module [test+proposed fix]

[Jakub B. <jak...@ge...>]

On Thu, Aug 30, 2007 at 07:28:49PM +0200, Miklos Szeredi wrote:
> > So we'd finally have something like:
> > 
> > new field in fuse_conn:
> > u64 version
> > 
> > new fields in fuse_inode:
> > u64 version
> > int(?) written
> > 
> > write:
> > spin_lock(&fc->lock)
> > inode->written++
> > spin_unlock(&fc->lock)
> > ... write request, i_size update
> > spin_lock(&fc->lock)
> > inode->version = ++(fc->version)
> > inode->written--
> > spin_unlock(&fc->lock)
> > 
> > setattr:
> > spin_lock(&fc->lock)
> > inode->written++
> > spin_unlock(&fc->lock)
> > ... setattr request, vmtruncate etc., i_size update
> > spin_lock(&fc->lock)
> > inode->version = ++(fc->version)
> > inode->written--
> > spin_unlock(&fc->lock)
> > 
> > getattr/lookup:
> > spin_lock(&fc->lock)
> > v1 = fs_version
> > spin_unlock(&fc->lock)
> > ... getattr/lookup request
> > spin_lock(&fc->lock)
> > v2 = fs_version
> > if((v1 == v2) && !inode->written) {
> >     ...update attr
> > } else {
> >     ...invalidate attr
> > }
> > spin_unlock(&fc->lock)
> > 
> 
> Yes, this is what I was thinking about.
> 
> > In this solution (with lock still held during attr update/invalidation)
> > I don't see any race scenario currently.
> > But there is another problem: getattr must return valid attributes, so
> > without inode locking it would need to repeat whole action (with
> > userspace request) until attributes are valid; and during countinuous
> > write it could be many times to complete whole operation without being
> > disturbed.
> 
> Well, the getattr() request can actually return the attributes it got
> from userspace.  Yes, it raced with the write, but that doesn't
> matter, the attributes _are_ valid, we just don't know if it is valid
> before the write or after.
> 
> So the only important thing is to not update the _cached_ attributes
> in that case.

Right. And finally solution looks correctly to me.

Do you expect to release fuse containing these changes any soon, or
there are some issues delaying it?


-- 
Jakub Bogusz
Gemius SA
http://gemius.com/

[fuse-devel] do_forget() leak a fuse_req

[Philippe E. <ph...@wa...>]

running into some memory leak, I found than do_forget() need
a fuse_reply_none(req); patch attached.

-- 
Phe

Re: [fuse-devel] How to start using FUSE

[Antonio M. <ant...@ic...>]

On Sat, Sep 01, 2007 at 04:21:00PM -0700, pavan krishnamurthy wrote:
> I have written a simple program
> 
> #include <stdio.h>
> #include<fuse.h>
> main()
> {
> int i=0;
> printf("helo world");
> }
> 
> when i try to compile this its giving me a error
> 
> In file included from /usr/include/fuse/fuse.h:23,
>                  from /usr/include/fuse.h:9,
>                  from test1.c:4:
> /usr/include/fuse/fuse_common.h:30:2: error: #error Please add -D_FILE_OFFSET_BITS=64 to your compile flags!
                                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> any pointers how to resolve this or have i made some silly mistake..

Sometimes reading the error messages can be very useful...

.a.

-- 
Antonio Messina

email: ant...@ic...   |  The Abdus Salam ICTP
phone: +39 040-2240-691          |  Strada Costiera, 11
fax:   +39 040-224531            |  34016 Trieste, Italy

Re: [fuse-devel] How to start using FUSE

[ds <iv...@gm...>]

compile it like this:

gcc -Wall `pkg-config fuse --cflags --libs`  yourfile.c ...

make sure that you have pkg-config.

2007/9/2, pavan krishnamurthy <pav...@gm...>:
> I have written a simple program
>
> #include <stdio.h>
> #include<fuse.h>
> main()
> {
> int i=0;
> printf("helo world");
> }
>
> when i try to compile this its giving me a error
>
> In file included from /usr/include/fuse/fuse.h:23,
>                  from /usr/include/fuse.h:9,
>                  from test1.c:4:
> /usr/include/fuse/fuse_common.h:30:2: error: #error Please add
> -D_FILE_OFFSET_BITS=64 to your compile flags!
>
> any pointers how to resolve this or have i made some silly mistake..
>
>
> On 9/1/07, css <cs...@sw...> wrote:
> > > Hi
> > > I am new to using FUSE. I am confused how to use FUSE. Are there any
> > > tutorials how to use this library or if somebody points me how to
> > > start developing using FUSE it would be great
> >
> > If I understand you correctly, you are searching for something like a
> > documentation. I would also  be interested in something like that, I
> > didnt find it yet, if anyone knows one, please also tell me.
> >
> > A very helpful thing for me was the Include-File fuse.h where most
> > functions are at least a little documented.
> > http://fuse.sourceforge.net/wiki/index.php/FUSE%20tutorial?PHPSESSID=6c210bc733b04a32a78baacaaf099899
> > aims to become a tutorial since one year now but noone seems to be
> > interested in it.
> > http://fuse.sourceforge.net/wiki/index.php/Documentation is at least a
> > little helpful.
> >
> > You should watch the examples given and read the comments in the
> > fuse.h, and take some time to "experiment" with it.
> >
> > Well, I know enough to build small (mostly useless) Filesystems
> > meanwhile. If you know enough about it maybe write a real tutorial
> > ;-).
> >
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> fuse-devel mailing list
> fus...@li...
> https://lists.sourceforge.net/lists/listinfo/fuse-devel
>

[fuse-devel] when mkdir is executed results in permission denied

[pavan k. <pav...@gm...>]

Hi all
I implemented mkdir function.
when i try to do mkdir on my file system it results in

"mkdir: cannot create directory `bcd/abc': Permission denied"

I have also implemented getattr , chmod and when i do chmod i get

chmod: changing permissions of `/home/pavank/bcd': Numerical result out of range

any pointers to resolve this.

thanks,
pavan

Re: [fuse-devel] How to start using FUSE

[pavan k. <pav...@gm...>]

I have written a simple program

#include <stdio.h>
#include<fuse.h>
main()
{
int i=0;
printf("helo world");
}

when i try to compile this its giving me a error

In file included from /usr/include/fuse/fuse.h:23,
                 from /usr/include/fuse.h:9,
                 from test1.c:4:
/usr/include/fuse/fuse_common.h:30:2: error: #error Please add
-D_FILE_OFFSET_BITS=64 to your compile flags!

any pointers how to resolve this or have i made some silly mistake..


On 9/1/07, css <cs...@sw...> wrote:
> > Hi
> > I am new to using FUSE. I am confused how to use FUSE. Are there any
> > tutorials how to use this library or if somebody points me how to
> > start developing using FUSE it would be great
>
> If I understand you correctly, you are searching for something like a
> documentation. I would also  be interested in something like that, I
> didnt find it yet, if anyone knows one, please also tell me.
>
> A very helpful thing for me was the Include-File fuse.h where most
> functions are at least a little documented.
> http://fuse.sourceforge.net/wiki/index.php/FUSE%20tutorial?PHPSESSID=6c210bc733b04a32a78baacaaf099899
> aims to become a tutorial since one year now but noone seems to be
> interested in it.
> http://fuse.sourceforge.net/wiki/index.php/Documentation is at least a
> little helpful.
>
> You should watch the examples given and read the comments in the
> fuse.h, and take some time to "experiment" with it.
>
> Well, I know enough to build small (mostly useless) Filesystems
> meanwhile. If you know enough about it maybe write a real tutorial
> ;-).
>

Re: [fuse-devel] How to start using FUSE

[css <cs...@sw...>]

> Hi
> I am new to using FUSE. I am confused how to use FUSE. Are there any
> tutorials how to use this library or if somebody points me how to
> start developing using FUSE it would be great

If I understand you correctly, you are searching for something like a
documentation. I would also  be interested in something like that, I
didnt find it yet, if anyone knows one, please also tell me.

A very helpful thing for me was the Include-File fuse.h where most
functions are at least a little documented.
http://fuse.sourceforge.net/wiki/index.php/FUSE%20tutorial?PHPSESSID=6c210bc733b04a32a78baacaaf099899
aims to become a tutorial since one year now but noone seems to be
interested in it.
http://fuse.sourceforge.net/wiki/index.php/Documentation is at least a
little helpful.

You should watch the examples given and read the comments in the
fuse.h, and take some time to "experiment" with it.

Well, I know enough to build small (mostly useless) Filesystems
meanwhile. If you know enough about it maybe write a real tutorial
;-).

[fuse-devel] How to start using FUSE

[pavan k. <pav...@gm...>]

Hi
I am new to using FUSE. I am confused how to use FUSE. Are there any
tutorials how to use this library or if somebody points me how to
start developing using FUSE it would be great

Thanks,
Pavan

Re: [fuse-devel] porting libfuse 2.7.0 to Solaris

[Mark P. <Mark.Phalan@Sun.COM>]

On Fri, 2007-08-31 at 13:05 +0200, Miklos Szeredi wrote:
> > >mount.c:282->290
> > >        struct pollfd pfd;
> > >
> > >        pfd.fd = fd;
> > >        pfd.events = 0;
> > >        res = poll(&pfd, 1, 0);
> > >        /* If file poll returns POLLERR on the device file descriptor,
> > >           then the filesystem is already unmounted */
> > >        if (res == 1 && (pfd.revents & POLLERR))
> > >            return;
> > >
> > >This doesn't work as desired on OpenSolaris with our FUSE kernel module.
> > >I'm trying to figure out whats it's trying to do..
> > >
> > >Is the Linux FUSE kernel module flagging something on the file
> > >descriptor (I can't look in the linux fuse kernel module due to
> > >licensing issues) which causes poll(2) to fail?
> 
> Yes, if the filesystem is unmounted it will clear a "connected"
> flag. and subsequent reads on that file descriptor will return with
> ENODEV error.
> 

Ok, makes sense.

Thanks for the info. I'll implement this in our kernel module.

Cheers,

-Mark

Re: [fuse-devel] porting libfuse 2.7.0 to Solaris

[Miklos S. <mi...@sz...>]

> >mount.c:282->290
> >        struct pollfd pfd;
> >
> >        pfd.fd = fd;
> >        pfd.events = 0;
> >        res = poll(&pfd, 1, 0);
> >        /* If file poll returns POLLERR on the device file descriptor,
> >           then the filesystem is already unmounted */
> >        if (res == 1 && (pfd.revents & POLLERR))
> >            return;
> >
> >This doesn't work as desired on OpenSolaris with our FUSE kernel module.
> >I'm trying to figure out whats it's trying to do..
> >
> >Is the Linux FUSE kernel module flagging something on the file
> >descriptor (I can't look in the linux fuse kernel module due to
> >licensing issues) which causes poll(2) to fail?

Yes, if the filesystem is unmounted it will clear a "connected"
flag. and subsequent reads on that file descriptor will return with
ENODEV error.

> >
> >What does it mean to call poll(2) with events set to 0? I had a look at
> >the standard and it doesn't seem to be defined...
> 
> I suppose it means "don't tell me anything", which seems kinda pointless, but
> nonetheless 'valid'.

>From SUS:

   POLLERR
       An error has occurred on the device or stream. This flag is
       only valid in the revents bitmask; it shall be ignored in the
       events member.

   [...]

   In addition, poll() shall set the POLLHUP, POLLERR, and POLLNVAL
   flag in revents if the condition is true, even if the application
   did not set the corresponding bit in events.

So giving a 0 events mask means, that it's only interested in HUP/ERR
events and nothing else.

> I wonder if testing for POLLRDHUP/WRHUP would not be better in the
> first place...(I do not know the exact FUSE internals, so that is
> just a guess).

Yeah, that would make sense.  However current fuse module only sets
POLLERR and not POLLHUP, so changing the library now would create a
compatibility problem.

But I'll fix the fuse module to set POLLHUP as well as POLLERR.

Miklos