[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F109928.9030004@linux.vnet.ibm.com>
Date: Fri, 13 Jan 2012 13:50:48 -0700
From: Allison Henderson <achender@...ux.vnet.ibm.com>
To: Andreas Dilger <adilger@...ger.ca>
CC: Ext4 Developers List <linux-ext4@...r.kernel.org>,
Lukas Czerner <lczerner@...hat.com>,
Zhen Liang <liang@...mcloud.com>
Subject: Re: working on extent locks for i_mutex
On 01/12/2012 09:01 PM, Andreas Dilger wrote:
> On 2012-01-12, at 8:01 PM, Allison Henderson wrote:
>> I know this is an old topic, but I am poking it again because I've had some work items wrap up, and Im planning on picking up on this one again. I am thinking about implementing extent locks to replace i_mutex. So I just wanted to touch base with folks and see what people are working on because I know there were some folks out there that were thing about doing similar solutions.
>>
>> A while ago I had done some investigation on where i_mutex is currently used, so I did a review and updated my list. Only one thing had been removed, but I will leave the list here since it was a while ago. Let me know if anyone has been working on similar concept. Thx!
>
> The in-ext4 users appear to all be file IO related, while the VFS functions
> are mostly directory related, though I don't see any mention of the callers
> of ext4_mkdir() or ext4_mknod() or ext4_create()?
Hmm, those ones didnt turn up when I was looking for i_mutex locking.
Though it would make sense that they would be locked. Did I over look
it in a helper function somewhere?
>
> For Lustre we developed a patch that allows parallel metadata operations on
> directories (e.g. concurrent lookup, mkdir, rmdir, create, unlink in a single
> directory) which would replace i_mutex for the namespace operations. Patch:
>
> http://git.whamcloud.com/?p=fs/lustre-release.git;a=blob;f=ldiskfs/kernel_patches/patches/ext4_pdirop-rhel6.patch;hb=HEAD
>
> though this in itself isn't enough to allow the VFS to do parallel directory
> operations. We're of course also interested in parallel file IO operations
> through the VFS for the client, though this hasn't been a focus of ours since
> we typically have a large number of clients doing IO concurrently.
>
I see, I will take a look at it, maybe there will be some things I can
borrow from it. Thx!
>> List of ext4 functions that lock i_mutex:
>> ext4_sync_file
>> ext4_fallocate
>> ext4_move_extents via two helper routines:
>> mext_inode_double_lock and mext_inode_double_unlock
>> ext4_ioctl (for the EXT4_IOC_SETFLAGS ioctl)
>> ext4_quota_write
>> ext4_llseek
>> ext4_end_io_work
>> ext4_ind_direct_IO (only while calling ext4_flush_completed_IO)
>>
>>
>> Functions called by vfs with i_mutex locked:
>> ext4_setattr
>> ext4_da_writepages
>> ext4_rmdir
>> ext4_unlink
>> ext4_symlink
>> ext4_link
>> ext4_rename
>> ext4_get_block
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> Cheers, Andreas
>
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists