xfs
[Top] [All Lists]

Re: review: s/i_flags_lock/i_inner_lock/g

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: review: s/i_flags_lock/i_inner_lock/g
From: David Chinner <dgc@xxxxxxx>
Date: Wed, 30 Apr 2008 07:29:43 +1000
Cc: Timothy Shimmin <tes@xxxxxxx>, xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <20080429053757.GA30708@infradead.org>
References: <4816AEEB.8090907@sgi.com> <20080429053757.GA30708@infradead.org>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
On Tue, Apr 29, 2008 at 01:37:57AM -0400, Christoph Hellwig wrote:
> On Tue, Apr 29, 2008 at 03:15:23PM +1000, Timothy Shimmin wrote:
> > Hi there,
> >
> > As part of future plans to cache incore versions of acls
> > off the inode, we want to protect its modification by a spin lock.
> > Dave suggested that we use the i_flags_lock but rename it to
> > reflect its more general purpose on other fields, such as "i_inner_lock".
> > This patch is then basically s/i_flags_lock/i_inner_lock/g.
> 
> Not too happpy about that, as I'd rather kill this lock in it's current
> form and use atomic bitops on the flags.  I'd rather use i_lock in the
> Linux inode for the ACLs.

The problem with that is that some of the flags work together and can't
be used as separate bitops. eg. xfs_finish_reclaim() and xfs_iget_core().
Hence they currently need to be protected by a spinlock.

Also, protecting something in the XFs inode with the linux inode lock
could have issues with the lifecycle differences between the inodes.
Just something to be careful of....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group


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