All of lore.kernel.org
 help / color / mirror / Atom feed
From: Allison Henderson <achender@linux.vnet.ibm.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>,
	Lukas Czerner <lczerner@redhat.com>,
	Zhen Liang <liang@whamcloud.com>
Subject: Re: working on extent locks for i_mutex
Date: Fri, 13 Jan 2012 13:50:48 -0700	[thread overview]
Message-ID: <4F109928.9030004@linux.vnet.ibm.com> (raw)
In-Reply-To: <4161CDFC-FEEB-4AAF-A0EA-B18F9FE8B7B1@dilger.ca>

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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
> Cheers, Andreas
>
>
>
>
>


  reply	other threads:[~2012-01-13 20:50 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-13  3:01 working on extent locks for i_mutex Allison Henderson
2012-01-13  4:01 ` Andreas Dilger
2012-01-13 20:50   ` Allison Henderson [this message]
2012-01-13  4:34 ` Dave Chinner
2012-01-13  4:34   ` Dave Chinner
2012-01-13  7:14   ` Tao Ma
2012-01-13  7:14     ` Tao Ma
2012-01-13 11:52     ` Dave Chinner
2012-01-13 11:52       ` Dave Chinner
2012-01-13 11:57       ` Tao Ma
2012-01-13 11:57         ` Tao Ma
2012-01-13 20:50   ` Allison Henderson
2012-01-13 20:50     ` Allison Henderson
2012-01-15 23:57     ` Dave Chinner
2012-01-15 23:57       ` Dave Chinner
2012-01-16 17:46       ` Allison Henderson
2012-01-18 12:02         ` Zheng Liu
2012-01-18 12:02           ` Zheng Liu
2012-01-19 21:16           ` Frank Mayhar
2012-01-19 21:16             ` Frank Mayhar
2012-01-20  2:26             ` Zheng Liu
2012-01-20  2:26               ` Zheng Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F109928.9030004@linux.vnet.ibm.com \
    --to=achender@linux.vnet.ibm.com \
    --cc=adilger@dilger.ca \
    --cc=lczerner@redhat.com \
    --cc=liang@whamcloud.com \
    --cc=linux-ext4@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.