linux.git/fs/9p, branch v2.6.32

9p: fix build breakage introduced by FS-Cache

2009-12-01T15:35:11+00:00

While building 2.6.32-rc8-git2 for Fedora I noticed the following thinko
in commit 201a15428bd54f83eccec8b7c64a04b8f9431204 ("FS-Cache: Handle
pages pending storage that get evicted under OOM conditions"):

  fs/9p/cache.c: In function '__v9fs_fscache_release_page':
  fs/9p/cache.c:346: error: 'vnode' undeclared (first use in this function)
  fs/9p/cache.c:346: error: (Each undeclared identifier is reported only once
  fs/9p/cache.c:346: error: for each function it appears in.)
  make[2]: *** [fs/9p/cache.o] Error 1

Fix the 9P filesystem to correctly construct the argument to
fscache_maybe_release_page().

Signed-off-by: Kyle McMartin 
Signed-off-by: Xiaotian Feng  [from identical patch]
Signed-off-by: Stefan Lippers-Hollmann  [from identical patch]
Signed-off-by: David Howells 
Signed-off-by: Linus Torvalds

FS-Cache: Handle pages pending storage that get evicted under OOM conditions

2009-11-19T18:11:35+00:00

Handle netfs pages that the vmscan algorithm wants to evict from the pagecache
under OOM conditions, but that are waiting for write to the cache.  Under these
conditions, vmscan calls the releasepage() function of the netfs, asking if a
page can be discarded.

The problem is typified by the following trace of a stuck process:

	kslowd005     D 0000000000000000     0  4253      2 0x00000080
	 ffff88001b14f370 0000000000000046 ffff880020d0d000 0000000000000007
	 0000000000000006 0000000000000001 ffff88001b14ffd8 ffff880020d0d2a8
	 000000000000ddf0 00000000000118c0 00000000000118c0 ffff880020d0d2a8
	Call Trace:
	 [] __fscache_wait_on_page_write+0x8b/0xa7 [fscache]
	 [] ? autoremove_wake_function+0x0/0x34
	 [] ? __fscache_check_page_write+0x63/0x70 [fscache]
	 [] nfs_fscache_release_page+0x4e/0xc4 [nfs]
	 [] nfs_release_page+0x3c/0x41 [nfs]
	 [] try_to_release_page+0x32/0x3b
	 [] shrink_page_list+0x316/0x4ac
	 [] shrink_inactive_list+0x392/0x67c
	 [] ? __mutex_unlock_slowpath+0x100/0x10b
	 [] ? trace_hardirqs_on_caller+0x10c/0x130
	 [] ? mutex_unlock+0x9/0xb
	 [] shrink_list+0x8d/0x8f
	 [] shrink_zone+0x278/0x33c
	 [] ? ktime_get_ts+0xad/0xba
	 [] try_to_free_pages+0x22e/0x392
	 [] ? isolate_pages_global+0x0/0x212
	 [] __alloc_pages_nodemask+0x3dc/0x5cf
	 [] grab_cache_page_write_begin+0x65/0xaa
	 [] ext3_write_begin+0x78/0x1eb
	 [] generic_file_buffered_write+0x109/0x28c
	 [] ? current_fs_time+0x22/0x29
	 [] __generic_file_aio_write+0x350/0x385
	 [] ? generic_file_aio_write+0x4a/0xae
	 [] generic_file_aio_write+0x60/0xae
	 [] do_sync_write+0xe3/0x120
	 [] ? autoremove_wake_function+0x0/0x34
	 [] ? __dentry_open+0x1a5/0x2b8
	 [] ? dentry_open+0x82/0x89
	 [] cachefiles_write_page+0x298/0x335 [cachefiles]
	 [] fscache_write_op+0x178/0x2c2 [fscache]
	 [] fscache_op_execute+0x7a/0xd1 [fscache]
	 [] slow_work_execute+0x18f/0x2d1
	 [] slow_work_thread+0x1c5/0x308
	 [] ? autoremove_wake_function+0x0/0x34
	 [] ? slow_work_thread+0x0/0x308
	 [] kthread+0x7a/0x82
	 [] child_rip+0xa/0x20
	 [] ? restore_args+0x0/0x30
	 [] ? tg_shares_up+0x171/0x227
	 [] ? kthread+0x0/0x82
	 [] ? child_rip+0x0/0x20

In the above backtrace, the following is happening:

 (1) A page storage operation is being executed by a slow-work thread
     (fscache_write_op()).

 (2) FS-Cache farms the operation out to the cache to perform
     (cachefiles_write_page()).

 (3) CacheFiles is then calling Ext3 to perform the actual write, using Ext3's
     standard write (do_sync_write()) under KERNEL_DS directly from the netfs
     page.

 (4) However, for Ext3 to perform the write, it must allocate some memory, in
     particular, it must allocate at least one page cache page into which it
     can copy the data from the netfs page.

 (5) Under OOM conditions, the memory allocator can't immediately come up with
     a page, so it uses vmscan to find something to discard
     (try_to_free_pages()).

 (6) vmscan finds a clean netfs page it might be able to discard (possibly the
     one it's trying to write out).

 (7) The netfs is called to throw the page away (nfs_release_page()) - but it's
     called with __GFP_WAIT, so the netfs decides to wait for the store to
     complete (__fscache_wait_on_page_write()).

 (8) This blocks a slow-work processing thread - possibly against itself.

The system ends up stuck because it can't write out any netfs pages to the
cache without allocating more memory.

To avoid this, we make FS-Cache cancel some writes that aren't in the middle of
actually being performed.  This means that some data won't make it into the
cache this time.  To support this, a new FS-Cache function is added
fscache_maybe_release_page() that replaces what the netfs releasepage()
functions used to do with respect to the cache.

The decisions fscache_maybe_release_page() makes are counted and displayed
through /proc/fs/fscache/stats on a line labelled "VmScan".  There are four
counters provided: "nos=N" - pages that weren't pending storage; "gon=N" -
pages that were pending storage when we first looked, but weren't by the time
we got the object lock; "bsy=N" - pages that we ignored as they were actively
being written when we looked; and "can=N" - pages that we cancelled the storage
of.

What I'd really like to do is alter the behaviour of the cancellation
heuristics, depending on how necessary it is to expel pages.  If there are
plenty of other pages that aren't waiting to be written to the cache that
could be ejected first, then it would be nice to hold up on immediate
cancellation of cache writes - but I don't see a way of doing that.

Signed-off-by: David Howells

9p: fix readdir corner cases

2009-11-02T14:43:45+00:00

The patch below also addresses a couple of other corner cases in readdir
seen with a large (e.g. 64k) msize.  I'm not sure what people think of
my co-opting of fid->aux here.  I'd be happy to rework if there's a better
way.

When the size of the user supplied buffer passed to readdir is smaller
than the data returned in one go by the 9P read request, v9fs_dir_readdir()
currently discards extra data so that, on the next call, a 9P read
request will be issued with offset < previous offset + bytes returned,
which voilates the constraint described in paragraph 3 of read(5) description.
This patch preseves the leftover data in fid->aux for use in the next call.

Signed-off-by: Jim Garlick 
Signed-off-by: Eric Van Hensbergen

9p: fix readlink

2009-11-02T14:43:45+00:00

I do not know if you've looked on the patch, but unfortunately it is
incorrect. A suggested better version is in this email (the old
version didn't work in case the user provided buffer was not long
enough - it incorrectly appended null byte on a position of last char,
and thus broke the contract of the readlink method). However, I'm
still not sure this is 100% correct thing to do, I think readlink is
supposed to return buffer without last null byte in all cases, but we
do return last null byte (even the old version).. on the other hand it
is likely unspecified what is in the remaining part of the buffer, so
null character may be fine there ;):

Signed-off-by: Martin Stava 
Signed-off-by: Eric Van Hensbergen

9p: fix a small bug in readdir for long directories

2009-11-02T14:43:44+00:00

Here is a proposed patch for bug in readdir. Listing of dirs with
many files fails without this patch.

Signed-off-by: Martin Stava 
Signed-off-by: Eric Van Hensbergen

9p: Add fscache support to 9p

2009-09-23T18:03:46+00:00

This patch adds a persistent, read-only caching facility for
9p clients using the FS-Cache caching backend.

When the fscache facility is enabled, each inode is associated
with a corresponding vcookie which is an index into the FS-Cache
indexing tree. The FS-Cache indexing tree is indexed at 3 levels:
- session object associated with each mount.
- inode/vcookie
- actual data (pages)

A cache tag is chosen randomly for each session. These tags can
be read off /sys/fs/9p/caches and can be passed as a mount-time
parameter to re-attach to the specified caching session.

Signed-off-by: Abhishek Kulkarni 
Signed-off-by: Eric Van Hensbergen

9p: Fix the incorrect update of inode size in v9fs_file_write()

2009-09-23T18:03:46+00:00

When using the cache=loose flags, the inode's size was not being
updated correctly on a remote write. Thus subsequent reads of
the whole file resulted in a truncated read. Fix it.

Signed-off-by: Abhishek Kulkarni 
Signed-off-by: Eric Van Hensbergen

9p: Use the i_size_[read, write]() macros instead of using inode->i_size directly.

2009-09-23T18:03:46+00:00

Change all occurrence of inode->i_size with i_size_read() or i_size_write()
as appropriate.

Signed-off-by: Abhishek Kulkarni 
Signed-off-by: Eric Van Hensbergen

9p: remove unnecessary v9fses->options which duplicates the mount string

2009-08-17T21:42:28+00:00

The mount options string is saved in sb->s_options. This patch removes
the redundant duplicating of the mount options. Also, since we are not
displaying anything special in show options, we replace v9fs_show_options
with generic_show_options for now.

Signed-off-by: Abhishek Kulkarni 
Signed-off-by: Eric Van Hensbergen

9p: Add missing cast for the error return value in v9fs_get_inode

2009-08-17T21:35:08+00:00

Cast the error return value (ENOMEM) in v9fs_get_inode() to its
correct type using ERR_PTR.

Signed-off-by: Abhishek Kulkarni 
Signed-off-by: Eric Van Hensbergen