linux.git/fs/inode.c, branch v2.6.32

vfs: optimize touch_time() too

2009-09-24T11:47:27+00:00

Do a similar optimization as earlier for touch_atime.  Getting the lock in
mnt_get_write is relatively costly, so try all avenues to avoid it first.

This patch is careful to still only update inode fields inside the lock
region.

This didn't show up in benchmarks, but it's easy enough to do.

[akpm@linux-foundation.org: fix typo in comment]
[hugh.dickins@tiscali.co.uk: fix inverted test of mnt_want_write_file()]
Signed-off-by: Andi Kleen 
Cc: Christoph Hellwig 
Cc: Valerie Aurora 
Cc: Al Viro 
Cc: Dave Hansen 
Signed-off-by: Hugh Dickins 
Signed-off-by: Andrew Morton 
Signed-off-by: Al Viro

vfs: optimization for touch_atime()

2009-09-24T11:47:26+00:00

Some benchmark testing shows touch_atime to be high up in profile logs for
IO intensive workloads.  Most likely that's due to the lock in
mnt_want_write().  Unfortunately touch_atime first takes the lock, and
then does all the other tests that could avoid atime updates (like noatime
or relatime).

Do it the other way round -- first try to avoid the update and only then
if that didn't succeed take the lock.  That works because none of the
atime avoidance tests rely on locking.

This also eliminates a goto.

Signed-off-by: Andi Kleen 
Cc: Christoph Hellwig 
Reviewed-by: Valerie Aurora 
Cc: Al Viro 
Cc: Dave Hansen 
Signed-off-by: Andrew Morton 
Signed-off-by: Al Viro

vfs: split generic_forget_inode() so that hugetlbfs does not have to copy it

2009-09-24T11:47:25+00:00

Hugetlbfs needs to do special things instead of truncate_inode_pages().
 Currently, it copied generic_forget_inode() except for
truncate_inode_pages() call which is asking for trouble (the code there
isn't trivial).  So create a separate function generic_detach_inode()
which does all the list magic done in generic_forget_inode() and call
it from hugetlbfs_forget_inode().

Signed-off-by: Jan Kara 
Cc: Al Viro 
Cc: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Signed-off-by: Al Viro

fs/inode.c: add dev-id and inode number for debugging in init_special_inode()

2009-09-24T11:47:24+00:00

Add device-id and inode number for better debugging.  This was suggested
by Andreas in one of the threads
http://article.gmane.org/gmane.comp.file-systems.ext4/12062 .

"If anyone has a chance, fixing this error message to be not-useless would
be good...  Including the device name and the inode number would help
track down the source of the problem."

Signed-off-by: Manish Katiyar 
Cc: Andreas Dilger 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Al Viro

fs: turn iprune_mutex into rwsem

2009-09-23T14:39:29+00:00

We have had a report of bad memory allocation latency during DVD-RAM (UDF)
writing.  This is causing the user's desktop session to become unusable.

Jan tracked the cause of this down to UDF inode reclaim blocking:

gnome-screens D ffff810006d1d598     0 20686      1
 ffff810006d1d508 0000000000000082 ffff810037db6718 0000000000000800
 ffff810006d1d488 ffffffff807e4280 ffffffff807e4280 ffff810006d1a580
 ffff8100bccbc140 ffff810006d1a8c0 0000000006d1d4e8 ffff810006d1a8c0
Call Trace:
 [] io_schedule+0x63/0xa5
 [] sync_buffer+0x3b/0x3f
 [] __wait_on_bit+0x47/0x79
 [] out_of_line_wait_on_bit+0x6a/0x77
 [] __wait_on_buffer+0x1f/0x21
 [] __bread+0x70/0x86
 [] :udf:udf_tread+0x38/0x3a
 [] :udf:udf_update_inode+0x4d/0x68c
 [] :udf:udf_write_inode+0x1d/0x2b
 [] __writeback_single_inode+0x1c0/0x394
 [] write_inode_now+0x7d/0xc4
 [] :udf:udf_clear_inode+0x3d/0x53
 [] clear_inode+0xc2/0x11b
 [] dispose_list+0x5b/0x102
 [] shrink_icache_memory+0x1dd/0x213
 [] shrink_slab+0xe3/0x158
 [] try_to_free_pages+0x177/0x232
 [] __alloc_pages+0x1fa/0x392
 [] alloc_page_vma+0x176/0x189
 [] __do_fault+0x10c/0x417
 [] handle_mm_fault+0x466/0x940
 [] do_page_fault+0x676/0xabf

This blocks with iprune_mutex held, which then blocks other reclaimers:

X             D ffff81009d47c400     0 17285  14831
 ffff8100844f3728 0000000000000086 0000000000000000 ffff81000000e288
 ffff81000000da00 ffffffff807e4280 ffffffff807e4280 ffff81009d47c400
 ffffffff805ff890 ffff81009d47c740 00000000844f3808 ffff81009d47c740
Call Trace:
 [] __mutex_lock_slowpath+0x72/0xa9
 [] mutex_lock+0x1e/0x22
 [] shrink_icache_memory+0x49/0x213
 [] shrink_slab+0xe3/0x158
 [] try_to_free_pages+0x177/0x232
 [] __alloc_pages+0x1fa/0x392
 [] alloc_pages_current+0xd1/0xd6
 [] __get_free_pages+0xe/0x4d
 [] __pollwait+0x5e/0xdf
 [] :nvidia:nv_kern_poll+0x2e/0x73
 [] do_select+0x308/0x506
 [] core_sys_select+0x1a6/0x254
 [] sys_select+0xb5/0x157

Now I think the main problem is having the filesystem block (and do IO) in
inode reclaim.  The problem is that this doesn't get accounted well and
penalizes a random allocator with a big latency spike caused by work
generated from elsewhere.

I think the best idea would be to avoid this.  By design if possible, or
by deferring the hard work to an asynchronous context.  If the latter,
then the fs would probably want to throttle creation of new work with
queue size of the deferred work, but let's not get into those details.

Anyway, the other obvious thing we looked at is the iprune_mutex which is
causing the cascading blocking.  We could turn this into an rwsem to
improve concurrency.  It is unreasonable to totally ban all potentially
slow or blocking operations in inode reclaim, so I think this is a cheap
way to get a small improvement.

This doesn't solve the whole problem of course.  The process doing inode
reclaim will still take the latency hit, and concurrent processes may end
up contending on filesystem locks.  So fs developers should keep these
problems in mind.

Signed-off-by: Nick Piggin 
Cc: Jan Kara 
Cc: Al Viro 
Cc: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

const: mark remaining inode_operations as const

2009-09-22T14:17:24+00:00

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fs: make sure data stored into inode is properly seen before unlocking new inode

2009-09-22T14:17:24+00:00

In theory it could happen that on one CPU we initialize a new inode but
clearing of I_NEW | I_LOCK gets reordered before some of the
initialization.  Thus on another CPU we return not fully uptodate inode
from iget_locked().

This seems to fix a corruption issue on ext3 mounted over NFS.

[akpm@linux-foundation.org: add some commentary]
Signed-off-by: Jan Kara 
Cc: Christoph Hellwig 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fs: remove bdev->bd_inode_backing_dev_info

2009-09-16T13:16:18+00:00

It has been unused since it was introduced in:

commit 520808bf20e90fdbdb320264ba7dd5cf9d47dcac
Author: Andrew Morton 
Date:   Fri May 21 00:46:17 2004 -0700

    [PATCH] block device layer: separate backing_dev_info infrastructure

So lets just kill it.

Acked-by: Jan Kara 
Signed-off-by: Jens Axboe

vfs: add __destroy_inode

2009-08-07T17:38:29+00:00

When we want to tear down an inode that lost the add to the cache race
in XFS we must not call into ->destroy_inode because that would delete
the inode that won the race from the inode cache radix tree.

This patch provides the __destroy_inode helper needed to fix this,
the actual fix will be in th next patch.  As XFS was the only reason
destroy_inode was exported we shift the export to the new __destroy_inode.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Eric Sandeen

vfs: fix inode_init_always calling convention

2009-08-07T17:38:25+00:00

Currently inode_init_always calls into ->destroy_inode if the additional
initialization fails.  That's not only counter-intuitive because
inode_init_always did not allocate the inode structure, but in case of
XFS it's actively harmful as ->destroy_inode might delete the inode from
a radix-tree that has never been added.  This in turn might end up
deleting the inode for the same inum that has been instanciated by
another process and cause lots of cause subtile problems.

Also in the case of re-initializing a reclaimable inode in XFS it would
free an inode we still want to keep alive.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Eric Sandeen