[PATCH 1/3] xfs: flag all buffers as metadata

[PATCH 1/3] xfs: flag all buffers as metadata

[Christoph Hellwig]

Now that REQ_META bios aren't treated specially in the CFQ I/O schedule
anymore, we can tag all buffers as metadata to make blktrace traces more
meaningful.  Note that we use buffers also to zero out partial blocks
in the preallocation / hole punching code, and while they operate on
data blocks the zeros written certainly aren't data.  I think this case
is borderline metadata enough to not bother special casing it.

Signed-off-by: Christoph Hellwig <hch@lst.de>

Index: linux-2.6/fs/xfs/linux-2.6/xfs_buf.c
===================================================================
--- linux-2.6.orig/fs/xfs/linux-2.6/xfs_buf.c	2011-07-25 23:50:03.288230279 +0200
+++ linux-2.6/fs/xfs/linux-2.6/xfs_buf.c	2011-07-25 23:50:22.208230167 +0200
@@ -1224,6 +1224,9 @@ _xfs_buf_ioapply(
 		rw = READ;
 	}
 
+	/* we only use the buffer cache for meta-data */
+	rw |= REQ_META;
+
 next_chunk:
 	atomic_inc(&bp->b_io_remaining);
 	nr_pages = BIO_MAX_SECTORS >> (PAGE_SHIFT - BBSHIFT);

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

[PATCH 2/3] xfs: prevent against ioend livelocks in xfs_file_fsync

[Christoph Hellwig]

We need to take some locks to prevent new ioends from coming in when we wait
for all existing ones to go away.  Up to Linux 3.0 that was done using the
i_mutex held by the VFS fsync code, but now that we are called without
it we need to take care of it ourselves.  Use the I/O lock instead of
i_mutex just like we do in other places.

Signed-off-by: Christoph Hellwig <hch@lst.de>

Index: linux-2.6/fs/xfs/linux-2.6/xfs_file.c
===================================================================
--- linux-2.6.orig/fs/xfs/linux-2.6/xfs_file.c	2011-07-25 23:50:35.081563423 +0200
+++ linux-2.6/fs/xfs/linux-2.6/xfs_file.c	2011-07-25 23:51:18.098229833 +0200
@@ -149,7 +149,9 @@ xfs_file_fsync(
 
 	xfs_iflags_clear(ip, XFS_ITRUNCATED);
 
+	xfs_ilock(ip, XFS_IOLOCK_SHARED);
 	xfs_ioend_wait(ip);
+	xfs_iunlock(ip, XFS_IOLOCK_SHARED);
 
 	if (mp->m_flags & XFS_MOUNT_BARRIER) {
 		/*

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

[PATCH 3/3] xfs: optimize the negative xattr caching

[Christoph Hellwig]

Since the addition of file capabilities every write needs to read xattrs to
check if we have any capabilities to clear.  In Linux 3.0 Andi Kleen added
a flag to cache the fact that we do not have any attributes on an inode.
Make sure to already mark a file as not having any attributes when reading
it from disk in case it doesn't even have an attribute fork.  Based on an
earlier patch from Andi Kleen.

Signed-off-by: Christoph Hellwig <hch@lst.de>

Index: linux-2.6/fs/xfs/linux-2.6/xfs_iops.c
===================================================================
--- linux-2.6.orig/fs/xfs/linux-2.6/xfs_iops.c	2011-07-25 23:49:23.011563852 +0200
+++ linux-2.6/fs/xfs/linux-2.6/xfs_iops.c	2011-07-25 23:49:50.281563691 +0200
@@ -1194,9 +1194,14 @@ xfs_setup_inode(
 		break;
 	}
 
-	/* if there is no attribute fork no ACL can exist on this inode */
-	if (!XFS_IFORK_Q(ip))
+	/*
+	 * If there is no attribute fork no ACL can exist on this inode,
+	 * and it can't have any file capabilities attached to it either.
+	 */
+	if (!XFS_IFORK_Q(ip)) {
+		inode_has_no_xattr(inode);
 		cache_no_acl(inode);
+	}
 
 	xfs_iflags_clear(ip, XFS_INEW);
 	barrier();

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH 1/3] xfs: flag all buffers as metadata

[Alex Elder]

On Tue, 2011-07-26 at 11:06 -0400, Christoph Hellwig wrote: 
> Now that REQ_META bios aren't treated specially in the CFQ I/O schedule
> anymore, we can tag all buffers as metadata to make blktrace traces more
> meaningful.  Note that we use buffers also to zero out partial blocks
> in the preallocation / hole punching code, and while they operate on
> data blocks the zeros written certainly aren't data.  I think this case
> is borderline metadata enough to not bother special casing it.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>

This looks good.  I plan to re-base the xfs master branch
after 3.1-rc1 is out, so I'll wait until after that to
commit this (and the others in this series).

If you want me to do something different, let me know.

Reviewed-by: Alex Elder <aelder@sgi.com>



_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH 2/3] xfs: prevent against ioend livelocks in xfs_file_fsync

[Alex Elder]

On Tue, 2011-07-26 at 11:07 -0400, Christoph Hellwig wrote:
> We need to take some locks to prevent new ioends from coming in when we wait
> for all existing ones to go away.  Up to Linux 3.0 that was done using the
> i_mutex held by the VFS fsync code, but now that we are called without
> it we need to take care of it ourselves.  Use the I/O lock instead of
> i_mutex just like we do in other places.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Looks good.

Reviewed-by: Alex Elder <aelder@sgi.com>


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH 3/3] xfs: optimize the negative xattr caching

[Alex Elder]

On Tue, 2011-07-26 at 11:07 -0400, Christoph Hellwig wrote:
> Since the addition of file capabilities every write needs to read xattrs to
> check if we have any capabilities to clear.  In Linux 3.0 Andi Kleen added
> a flag to cache the fact that we do not have any attributes on an inode.
> Make sure to already mark a file as not having any attributes when reading
> it from disk in case it doesn't even have an attribute fork.  Based on an
> earlier patch from Andi Kleen.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Looks good to me.

Reviewed-by: Alex Elder <aelder@sgi.com>


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH 1/3] xfs: flag all buffers as metadata

[Christoph Hellwig]

On Tue, Jul 26, 2011 at 05:38:55PM -0500, Alex Elder wrote:
> On Tue, 2011-07-26 at 11:06 -0400, Christoph Hellwig wrote: 
> > Now that REQ_META bios aren't treated specially in the CFQ I/O schedule
> > anymore, we can tag all buffers as metadata to make blktrace traces more
> > meaningful.  Note that we use buffers also to zero out partial blocks
> > in the preallocation / hole punching code, and while they operate on
> > data blocks the zeros written certainly aren't data.  I think this case
> > is borderline metadata enough to not bother special casing it.
> > 
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> This looks good.  I plan to re-base the xfs master branch
> after 3.1-rc1 is out, so I'll wait until after that to
> commit this (and the others in this series).

I'd prefer to get it out to Linus ASAP after some review.  Just
committing it to for-linus for now and later rebasing master on top
should do fine for that.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH 1/3] xfs: flag all buffers as metadata

[Alex Elder]

On Tue, 2011-07-26 at 18:40 -0400, Christoph Hellwig wrote:
> On Tue, Jul 26, 2011 at 05:38:55PM -0500, Alex Elder wrote:
> > On Tue, 2011-07-26 at 11:06 -0400, Christoph Hellwig wrote: 
> > > Now that REQ_META bios aren't treated specially in the CFQ I/O schedule
> > > anymore, we can tag all buffers as metadata to make blktrace traces more
> > > meaningful.  Note that we use buffers also to zero out partial blocks
> > > in the preallocation / hole punching code, and while they operate on
> > > data blocks the zeros written certainly aren't data.  I think this case
> > > is borderline metadata enough to not bother special casing it.
> > > 
> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > 
> > This looks good.  I plan to re-base the xfs master branch
> > after 3.1-rc1 is out, so I'll wait until after that to
> > commit this (and the others in this series).
> 
> I'd prefer to get it out to Linus ASAP after some review.  Just
> committing it to for-linus for now and later rebasing master on top
> should do fine for that.

OK, fine with me.  I'll get that process started this evening.

					-Alex

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs