1. 09 2月, 2010 3 次提交
  2. 27 1月, 2010 1 次提交
  3. 14 1月, 2010 1 次提交
  4. 01 12月, 2009 1 次提交
    • D
      9p: fix build breakage introduced by FS-Cache · 6f054164
      David Howells 提交于
      While building 2.6.32-rc8-git2 for Fedora I noticed the following thinko
      in commit 201a1542 ("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: NKyle McMartin <kyle@redhat.com>
      Signed-off-by: Xiaotian Feng <dfeng@redhat.com> [from identical patch]
      Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [from identical patch]
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6f054164
  5. 20 11月, 2009 1 次提交
    • D
      FS-Cache: Handle pages pending storage that get evicted under OOM conditions · 201a1542
      David Howells 提交于
      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:
      	 [<ffffffffa00782d8>] __fscache_wait_on_page_write+0x8b/0xa7 [fscache]
      	 [<ffffffff8104c0f1>] ? autoremove_wake_function+0x0/0x34
      	 [<ffffffffa0078240>] ? __fscache_check_page_write+0x63/0x70 [fscache]
      	 [<ffffffffa00b671d>] nfs_fscache_release_page+0x4e/0xc4 [nfs]
      	 [<ffffffffa00927f0>] nfs_release_page+0x3c/0x41 [nfs]
      	 [<ffffffff810885d3>] try_to_release_page+0x32/0x3b
      	 [<ffffffff81093203>] shrink_page_list+0x316/0x4ac
      	 [<ffffffff8109372b>] shrink_inactive_list+0x392/0x67c
      	 [<ffffffff813532fa>] ? __mutex_unlock_slowpath+0x100/0x10b
      	 [<ffffffff81058df0>] ? trace_hardirqs_on_caller+0x10c/0x130
      	 [<ffffffff8135330e>] ? mutex_unlock+0x9/0xb
      	 [<ffffffff81093aa2>] shrink_list+0x8d/0x8f
      	 [<ffffffff81093d1c>] shrink_zone+0x278/0x33c
      	 [<ffffffff81052d6c>] ? ktime_get_ts+0xad/0xba
      	 [<ffffffff81094b13>] try_to_free_pages+0x22e/0x392
      	 [<ffffffff81091e24>] ? isolate_pages_global+0x0/0x212
      	 [<ffffffff8108e743>] __alloc_pages_nodemask+0x3dc/0x5cf
      	 [<ffffffff81089529>] grab_cache_page_write_begin+0x65/0xaa
      	 [<ffffffff8110f8c0>] ext3_write_begin+0x78/0x1eb
      	 [<ffffffff81089ec5>] generic_file_buffered_write+0x109/0x28c
      	 [<ffffffff8103cb69>] ? current_fs_time+0x22/0x29
      	 [<ffffffff8108a509>] __generic_file_aio_write+0x350/0x385
      	 [<ffffffff8108a588>] ? generic_file_aio_write+0x4a/0xae
      	 [<ffffffff8108a59e>] generic_file_aio_write+0x60/0xae
      	 [<ffffffff810b2e82>] do_sync_write+0xe3/0x120
      	 [<ffffffff8104c0f1>] ? autoremove_wake_function+0x0/0x34
      	 [<ffffffff810b18e1>] ? __dentry_open+0x1a5/0x2b8
      	 [<ffffffff810b1a76>] ? dentry_open+0x82/0x89
      	 [<ffffffffa00e693c>] cachefiles_write_page+0x298/0x335 [cachefiles]
      	 [<ffffffffa0077147>] fscache_write_op+0x178/0x2c2 [fscache]
      	 [<ffffffffa0075656>] fscache_op_execute+0x7a/0xd1 [fscache]
      	 [<ffffffff81082093>] slow_work_execute+0x18f/0x2d1
      	 [<ffffffff8108239a>] slow_work_thread+0x1c5/0x308
      	 [<ffffffff8104c0f1>] ? autoremove_wake_function+0x0/0x34
      	 [<ffffffff810821d5>] ? slow_work_thread+0x0/0x308
      	 [<ffffffff8104be91>] kthread+0x7a/0x82
      	 [<ffffffff8100beda>] child_rip+0xa/0x20
      	 [<ffffffff8100b87c>] ? restore_args+0x0/0x30
      	 [<ffffffff8102ef83>] ? tg_shares_up+0x171/0x227
      	 [<ffffffff8104be17>] ? kthread+0x0/0x82
      	 [<ffffffff8100bed0>] ? 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: NDavid Howells <dhowells@redhat.com>
      201a1542
  6. 02 11月, 2009 3 次提交
    • E
      9p: fix readdir corner cases · 3e2796a9
      Eric Van Hensbergen 提交于
      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: NJim Garlick <garlick@llnl.gov>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      3e2796a9
    • M
      9p: fix readlink · 2511cd0b
      Martin Stava 提交于
      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: NMartin Stava <martin.stava@gmail.com>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      2511cd0b
    • M
      9p: fix a small bug in readdir for long directories · f91b9099
      Martin Stava 提交于
      Here is a proposed patch for bug in readdir. Listing of dirs with
      many files fails without this patch.
      Signed-off-by: NMartin Stava <martin.stava@gmail.com>
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      f91b9099
  7. 24 9月, 2009 3 次提交
  8. 18 8月, 2009 9 次提交
  9. 15 7月, 2009 1 次提交
  10. 17 6月, 2009 1 次提交
  11. 09 5月, 2009 3 次提交
  12. 28 3月, 2009 2 次提交
  13. 22 1月, 2009 1 次提交
  14. 20 12月, 2008 3 次提交
  15. 14 11月, 2008 1 次提交
  16. 23 10月, 2008 1 次提交
  17. 18 10月, 2008 5 次提交
    • M
      9p: fix device file handling · 57c7b4e6
      Magnus Deininger 提交于
      In v9fs_get_inode(), for block, as well as char devices (in theory), 
      the function init_special_inode() is called to set up callback functions 
      for file ops. this function uses the file mode's value to determine whether 
      to use block or char dev functions. In v9fs_inode_from_fid(), the function 
      p9mode2unixmode() is used, but for all devices it initially returns S_IFBLK, 
      then uses v9fs_get_inode() to initialise a new inode, then finally uses 
      v9fs_stat2inode(), which would determine whether the inode is a block or 
      character device. However, at that point init_special_inode() had already 
      decided to use the block device functions, so even if the inode's mode is 
      turned to a character device, the block functions are still used to operate 
      on them. The attached patch simply calls init_special_inode() again for devices 
      after parsing device node data in v9fs_stat2inode() so that the proper functions 
      are used.
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      
      
      57c7b4e6
    • E
      9p: eliminate depricated conv functions · 02da398b
      Eric Van Hensbergen 提交于
      Remove depricated conv functions which have been replaced with new 
      protocol routines.
      
      This patch also reworks the one instance of the file-system code which
      directly calls conversion routines (to accomplish unpacking dirreads).
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      
      
      02da398b
    • E
      9p: rework client code to use new protocol support functions · 51a87c55
      Eric Van Hensbergen 提交于
      Now that the new protocol functions are in place, this patch switches
      the client code to using the new support code.
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      
      
      51a87c55
    • E
      9p: move dirread to fs layer · 06b55b46
      Eric Van Hensbergen 提交于
      Currently reading a directory is implemented in the client code.
      This function is not actually a wire operation, but a meta operation 
      which calls read operations and processes the results.
      
      This patch moves this functionality to the fs layer and calls component
      wire operations instead of constructing their packets.  This provides a 
      cleaner separation and will help when we reorganize the client functions
      and protocol processing methods.
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      
      
      
      06b55b46
    • E
      9p: adjust 9p vfs write operation · dfb0ec2e
      Eric Van Hensbergen 提交于
      Currently, the 9p net wire operation ensures that all data is sent by sending
      multiple packets if the data requested is larger than the msize.  This is
      better handled in the vfs code so that we can simplify wire operations to 
      being concerned with only putting data onto and taking data off of the wire.
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      
      
      
      dfb0ec2e