| To: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH 0/7] extent list locking fixes V2 |
| From: | Ben Myers <bpm@xxxxxxx> |
| Date: | Fri, 6 Dec 2013 11:57:26 -0600 |
| Cc: | xfs@xxxxxxxxxxx |
| Delivered-to: | xfs@xxxxxxxxxxx |
| In-reply-to: | <20131206175444.GA25669@xxxxxxxxxxxxx> |
| References: | <20131206164819.371654241@xxxxxxxxxxxxxxxxxxxxxx> <20131206173729.GR1935@xxxxxxx> <20131206175444.GA25669@xxxxxxxxxxxxx> |
| User-agent: | Mutt/1.5.20 (2009-06-14) |
On Fri, Dec 06, 2013 at 09:54:44AM -0800, Christoph Hellwig wrote:
> On Fri, Dec 06, 2013 at 11:37:29AM -0600, Ben Myers wrote:
> > Hey Christoph,
> >
> > On Fri, Dec 06, 2013 at 08:48:19AM -0800, Christoph Hellwig wrote:
> > > Fixed the review feedback, and includes Bens original patch for
> > > completeness.
> >
> > I ran your initial series overnight with xfstests... oddly I hit this:
>
> I think I understand the problem:
>
> uint
> xfs_ilock_map_shared(
> xfs_inode_t *ip)
> {
> uint lock_mode;
>
> if ((ip->i_d.di_format == XFS_DINODE_FMT_BTREE) &&
> ((ip->i_df.if_flags & XFS_IFEXTENTS) == 0)) {
> lock_mode = XFS_ILOCK_EXCL;
> } else {
> lock_mode = XFS_ILOCK_SHARED;
> }
>
> xfs_ilock(ip, lock_mode);
> return lock_mode;
> }
>
> This only looks at the data fork, while we'd need to use it for the
> fork we plan to operate on. Looks like we'll need some bigger surgery
> this area.
Ah, that makes sense. Maybe just add a flags arg?
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 0/7] extent list locking fixes V2, Christoph Hellwig |
|---|---|
| Next by Date: | Re: [PATCH 0/7] extent list locking fixes V2, Christoph Hellwig |
| Previous by Thread: | Re: [PATCH 0/7] extent list locking fixes V2, Christoph Hellwig |
| Next by Thread: | Re: [PATCH 0/7] extent list locking fixes V2, Christoph Hellwig |
| Indexes: | [Date] [Thread] [Top] [All Lists] |