[Top] [All Lists]

Re: [PATCH 0/7] extent list locking fixes V2

To: Ben Myers <bpm@xxxxxxx>
Subject: Re: [PATCH 0/7] extent list locking fixes V2
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Fri, 6 Dec 2013 09:54:44 -0800
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20131206173729.GR1935@xxxxxxx>
References: <20131206164819.371654241@xxxxxxxxxxxxxxxxxxxxxx> <20131206173729.GR1935@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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:

        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.

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