[Top] [All Lists]

Re: [PATCH 0/5] do not take the iolock in inode reclaim context

To: Sage Weil <sage@xxxxxxxxxxx>
Subject: Re: [PATCH 0/5] do not take the iolock in inode reclaim context
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Tue, 17 Jul 2012 12:27:21 -0500
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, sage@xxxxxxxxxxxx, xfs@xxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1207170845060.30672@xxxxxxxxxxxxxxxxxx>
References: <20120704151328.928543446@xxxxxxxxxxxxxxxxxxxxxx> <20120717071923.GD15473@xxxxxxxxxxxxx> <alpine.DEB.2.00.1207170845060.30672@xxxxxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
On 07/17/12 10:46, Sage Weil wrote:
On Tue, 17 Jul 2012, Christoph Hellwig wrote:
ping/  I'd really like to get this queued up for 3.6

I forget if I mentioned this before, but I pulled this series into our
testing branch and have had no problems (aside from the last patch not
applying to my tree) in qa (ceph on xfs) over the last couple of weeks.



The patch "5-5-xfs-remove-iolock-lock-classes.patch" does not cleanly
apply because the comment that the patch is trying to remove in
xfs_iget.c has the following character sequence "<D1><95>" that the
mailer converted to a "?". It is easy enough to hand patch:

* Define xfs inode iolock lockdep classes. We need to ensure that all active * inodes are considered the same for lockdep purposes, including inodes that * are recycled through the XFS_IRECLAIMABLE state. This is the the only way to
 * guarantee the locks are considered the same when there are multiple lock
* initialisation site<D1><95>. Also, define a reclaimable inode class so it is

--Mark Tinguely.

<Prev in Thread] Current Thread [Next in Thread>