linux.git/fs/fuse/dev.c, branch v2.6.38

fuse: allow batching of FORGET requests

2010-12-07T19:16:56+00:00

Terje Malmedal reports that a fuse filesystem with 32 million inodes
on a machine with lots of memory can take up to 30 minutes to process
FORGET requests when all those inodes are evicted from the icache.

To solve this, create a BATCH_FORGET request that allows up to about
8000 FORGET requests to be sent in a single message.

This request is only sent if userspace supports interface version 7.16
or later, otherwise fall back to sending individual FORGET messages.

Reported-by: Terje Malmedal 
Signed-off-by: Miklos Szeredi

fuse: separate queue for FORGET requests

2010-12-07T19:16:56+00:00

Terje Malmedal reports that a fuse filesystem with 32 million inodes
on a machine with lots of memory can go unresponsive for up to 30
minutes when all those inodes are evicted from the icache.

The reason is that FORGET messages, sent when the inode is evicted,
are queued up together with regular filesystem requests, and while the
huge queue of FORGET messages are processed no other filesystem
operation can proceed.

Since a full fuse request structure is allocated for each inode, these
take up quite a bit of memory as well.

To solve these issues, create a slim 'fuse_forget_link' structure
containing just the minimum of information required to send the FORGET
request and chain these on a separate queue.

When userspace is asking for a request make sure that FORGET and
non-FORGET requests are selected fairly: for each 8 non-FORGET allow
16 FORGET requests.  This will make sure FORGETs do not pile up, yet
other requests are also allowed to proceed while the queued FORGETs
are processed.

Reported-by: Terje Malmedal 
Signed-off-by: Miklos Szeredi

fuse: use release_pages()

2010-10-28T01:03:17+00:00

Replace iterated page_cache_release() with release_pages(), which is
faster and shorter.

Needs release_pages() to be exported to modules.

Suggested-by: Andrew Morton 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fuse: use clear_highpage() and KM_USER0 instead of KM_USER1

2010-10-26T23:52:13+00:00

Commit 7909b1c640 ("fuse: don't use atomic kmap") removed KM_USER0 usage
from fuse/dev.c.  Switch KM_USER1 uses to KM_USER0 for clarity.  Also
replace open coded clear_highpage().

Signed-off-by: Miklos Szeredi 
Cc: Jan Beulich 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

use clear_page()/copy_page() in favor of memset()/memcpy() on whole pages

2010-10-26T23:52:13+00:00

After all that's what they are intended for.

Signed-off-by: Jan Beulich 
Cc: Miklos Szeredi 
Cc: "Eric W. Biederman" 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fuse: Initialize total_len in fuse_retrieve()

2010-10-04T08:45:32+00:00

fs/fuse/dev.c:1357: warning: ‘total_len’ may be used uninitialized in this
function

Initialize total_len to zero, else its value will be undefined.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Miklos Szeredi

fuse: fix lock annotations

2010-09-07T11:42:41+00:00

Sparse doesn't understand lock annotations of the form
__releases(&foo->lock).  Change them to __releases(foo->lock).  Same
for __acquires().

Signed-off-by: Miklos Szeredi

fuse: flush background queue on connection close

2010-09-07T11:42:41+00:00

David Bartly reported that fuse can hang in fuse_get_req_nofail() when
the connection to the filesystem server is no longer active.

If bg_queue is not empty then flush_bg_queue() called from
request_end() can put more requests on to the pending queue.  If this
happens while ending requests on the processing queue then those
background requests will be queued to the pending list and never
ended.

Another problem is that fuse_dev_release() didn't wake up processes
sleeping on blocked_waitq.

Solve this by:

 a) flushing the background queue before calling end_requests() on the
    pending and processing queues

 b) setting blocked = 0 and waking up processes waiting on
    blocked_waitq()

Thanks to David for an excellent bug report.

Reported-by: David Bartley 
Signed-off-by: Miklos Szeredi 
CC: stable@kernel.org

fuse: add retrieve request

2010-07-12T12:41:40+00:00

Userspace filesystem can request data to be retrieved from the inode's
mapping.  This request is synchronous and the retrieved data is queued
as a new request.  If the write to the fuse device returns an error
then the retrieve request was not completed and a reply will not be
sent.

Only present pages are returned in the retrieve reply.  Retrieving
stops when it finds a non-present page and only data prior to that is
returned.

This request doesn't change the dirty state of pages.

Signed-off-by: Miklos Szeredi

fuse: add store request

2010-07-12T12:41:40+00:00

Userspace filesystem can request data to be stored in the inode's
mapping.  This request is synchronous and has no reply.  If the write
to the fuse device returns an error then the store request was not
fully completed (but may have updated some pages).

If the stored data overflows the current file size, then the size is
extended, similarly to a write(2) on the filesystem.

Pages which have been completely stored are marked uptodate.

Signed-off-by: Miklos Szeredi