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

dquot: move dquot initialization responsibility into the filesystem

2010-03-04T23:20:30+00:00

Currently various places in the VFS call vfs_dq_init directly.  This means
we tie the quota code into the VFS.  Get rid of that and make the
filesystem responsible for the initialization.   For most metadata operations
this is a straight forward move into the methods, but for truncate and
open it's a bit more complicated.

For truncate we currently only call vfs_dq_init for the sys_truncate case
because open already takes care of it for ftruncate and open(O_TRUNC) - the
new code causes an additional vfs_dq_init for those which is harmless.

For open the initialization is moved from do_filp_open into the open method,
which means it happens slightly earlier now, and only for regular files.
The latter is fine because we don't need to initialize it for operations
on special files, and we already do it as part of the namespace operations
for directories.

Add a dquot_file_open helper that filesystems that support generic quotas
can use to fill in ->open.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Jan Kara

dquot: move dquot drop responsibility into the filesystem

2010-03-04T23:20:29+00:00

Currently clear_inode calls vfs_dq_drop directly.  This means
we tie the quota code into the VFS.  Get rid of that and make the
filesystem responsible for the drop inside the ->clear_inode
superblock operation.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Jan Kara

kill I_LOCK

2009-12-17T16:03:25+00:00

After I_SYNC was split from I_LOCK the leftover is always used together with
I_NEW and thus superflous.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Al Viro

LSM: imbed ima calls in the security hooks

2009-10-25T04:22:48+00:00

Based on discussions on LKML and LSM, where there are consecutive
security_ and ima_ calls in the vfs layer, move the ima_ calls to
the existing security_ hooks.

Signed-off-by: Mimi Zohar 
Signed-off-by: James Morris

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