Re: [Avf-fuse-dev] Short reads

[<Mik...@et...>]

> Does this simplify things significantly?  If it isn't much of a
> difference, I'd like to suggest doing it the other way: many people
> (like me) implement their fuse read function in terms of read(), and
> read() can return early.

No.  Read from a pipe/socket can be short, but read from a file can't. 

Unfortunatly it does complicate things to handle this correctly.  If
I implement the for-loop in the kernel you'll gain nothing. 

> It's true that a for loop in the read function can handle this, but
> the read size that is asked for by the kernel is 64k now - I often
> don't have 64k ready to give, and waiting to return until I do really
> hurts performance.  In fuse 1.0, the read size was only 4k, so this is
> going to be a bigger problem when 1.1 comes out.

OK, this _is_ a problem.  Maybe the simplest is just to have a mount
flag which disables read-combining, so filesystems which are slower
(and so which don't benefit much from large reads anyway) can have 4k
reads.

> This is not to say that I don't like the 64k read size - I think it's
> great.  It's only a problem when I don't have all of it, and so must
> block until I do.

But that is the rule.  The actual read which invoked the FUSE read
operation must not return until all data is available.  And since
reads go through the page cache the read request cannot be shorter
then the page size (4k usually).  The blocking is either in the
userspace daemon or in the kernel, but I think it's cleaner if it's in
userspace.

Thanks for the feedback BTW!

Miklos