[002/119] vfs: support FS_XFLAG_REFLINK and FS_XFLAG_COWEXTSIZE
diff mbox

Message ID 146612628567.12839.3246258786290141903.stgit@birch.djwong.org
State New
Headers show

Commit Message

Darrick J. Wong June 17, 2016, 1:18 a.m. UTC
Introduce XFLAGs for the new XFS reflink inode flag and the CoW extent
size hint, and actually plumb the CoW extent size hint into the fsxattr
structure.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
---
 include/uapi/linux/fs.h |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)



--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Christoph Hellwig June 17, 2016, 11:41 a.m. UTC | #1
On Thu, Jun 16, 2016 at 06:18:05PM -0700, Darrick J. Wong wrote:
> Introduce XFLAGs for the new XFS reflink inode flag and the CoW extent
> size hint, and actually plumb the CoW extent size hint into the fsxattr
> structure.
> 
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>

Should go behind all the updates that are useful without any new
rmap or reflink functionality.  In fact it would be great if you
could send out a series with just those little fixes and cleanups
first.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Brian Foster June 17, 2016, 12:16 p.m. UTC | #2
On Fri, Jun 17, 2016 at 04:41:17AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 16, 2016 at 06:18:05PM -0700, Darrick J. Wong wrote:
> > Introduce XFLAGs for the new XFS reflink inode flag and the CoW extent
> > size hint, and actually plumb the CoW extent size hint into the fsxattr
> > structure.
> > 
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> 
> Should go behind all the updates that are useful without any new
> rmap or reflink functionality.  In fact it would be great if you
> could send out a series with just those little fixes and cleanups
> first.
> 

I'd take that a step further and suggest the entire series be split into
independent feature series, as appropriate. Unless I'm missing
something, I don't think there's any reason these all need to be bundled
together. Further, my expectation is that they probably end up being
merged as independent units, so I think it's easier for everybody for
Darrick to carve that up on the logical boundaries rather than assume
all reviewers and maintainer are going to do so consistently.

Note that I'm not saying this has to be reposted.. I think I can pull
off the rmap bits for the time being. I'm just suggesting that if a
repost is required from this point forward for any of the logical
subunits (deps, rmap, reflink, scrub), I'd suggest to post, version and
changelog those units independently.

Brian

> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Christoph Hellwig June 17, 2016, 3:06 p.m. UTC | #3
On Fri, Jun 17, 2016 at 08:16:05AM -0400, Brian Foster wrote:
> I'd take that a step further and suggest the entire series be split into
> independent feature series, as appropriate.

Yes, that's what I meant.  I just didn't manage to get to the rest yet.

> off the rmap bits for the time being. I'm just suggesting that if a
> repost is required from this point forward for any of the logical
> subunits (deps, rmap, reflink, scrub), I'd suggest to post, version and
> changelog those units independently.

Agreed.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Darrick J. Wong June 17, 2016, 4:54 p.m. UTC | #4
On Fri, Jun 17, 2016 at 08:16:05AM -0400, Brian Foster wrote:
> On Fri, Jun 17, 2016 at 04:41:17AM -0700, Christoph Hellwig wrote:
> > On Thu, Jun 16, 2016 at 06:18:05PM -0700, Darrick J. Wong wrote:
> > > Introduce XFLAGs for the new XFS reflink inode flag and the CoW extent
> > > size hint, and actually plumb the CoW extent size hint into the fsxattr
> > > structure.
> > > 
> > > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > 
> > Should go behind all the updates that are useful without any new
> > rmap or reflink functionality.  In fact it would be great if you
> > could send out a series with just those little fixes and cleanups
> > first.
> > 
> 
> I'd take that a step further and suggest the entire series be split into
> independent feature series, as appropriate. Unless I'm missing
> something, I don't think there's any reason these all need to be bundled
> together. Further, my expectation is that they probably end up being
> merged as independent units, so I think it's easier for everybody for
> Darrick to carve that up on the logical boundaries rather than assume
> all reviewers and maintainer are going to do so consistently.
> 
> Note that I'm not saying this has to be reposted.. I think I can pull
> off the rmap bits for the time being. I'm just suggesting that if a
> repost is required from this point forward for any of the logical
> subunits (deps, rmap, reflink, scrub), I'd suggest to post, version and
> changelog those units independently.

I'd thought about continuing my old practice of listing which patches
go with which feature... but then got lazy. :(  Cleanups/rmap/reflink/scrub
actually are in their own contiguous sections of the patchbomb, though that
isn't obvious from looking at it.

You ought to be able to pull only as far as the end of the rmap series and
still have a working XFS.  I only did the intensive testing with the full
patchset, but the quick xfstests group ran fine with just the rmap pieces.

Kernel patches:
===============
Cleanups, 1-11
rmap + dependencies, 12-49
    Overlapped interval btree, 12-15
    Deferred operations, 16-22
    rmap, 23-49
reflink + dependencies, 50-111
    AG reservations, 50-52
    refcount btree, 53-68
    deferred remap, 69-73
    cow, 74-88
    reflink, 89-111
getfsmapx, 112
scrub, 113-119

xfsprogs:
=========
Cleanups, 1-15
rmap + deps, 16-70
    Overlapped interval btree, 16-19
    Deferred operations, 20-27
    rmap, 28-70
reflink + dependencies, 71-135
    AG reservations, 71-72
    refcount btree, 73-85
    deferred remap, 86-90
    reflink, 91-135
getfsmapx, 136-138
scrub, 139-145

--D

> 
> Brian
> 
> > _______________________________________________
> > xfs mailing list
> > xfs@oss.sgi.com
> > http://oss.sgi.com/mailman/listinfo/xfs
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Brian Foster June 17, 2016, 5:38 p.m. UTC | #5
On Fri, Jun 17, 2016 at 09:54:00AM -0700, Darrick J. Wong wrote:
> On Fri, Jun 17, 2016 at 08:16:05AM -0400, Brian Foster wrote:
> > On Fri, Jun 17, 2016 at 04:41:17AM -0700, Christoph Hellwig wrote:
> > > On Thu, Jun 16, 2016 at 06:18:05PM -0700, Darrick J. Wong wrote:
> > > > Introduce XFLAGs for the new XFS reflink inode flag and the CoW extent
> > > > size hint, and actually plumb the CoW extent size hint into the fsxattr
> > > > structure.
> > > > 
> > > > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > > 
> > > Should go behind all the updates that are useful without any new
> > > rmap or reflink functionality.  In fact it would be great if you
> > > could send out a series with just those little fixes and cleanups
> > > first.
> > > 
> > 
> > I'd take that a step further and suggest the entire series be split into
> > independent feature series, as appropriate. Unless I'm missing
> > something, I don't think there's any reason these all need to be bundled
> > together. Further, my expectation is that they probably end up being
> > merged as independent units, so I think it's easier for everybody for
> > Darrick to carve that up on the logical boundaries rather than assume
> > all reviewers and maintainer are going to do so consistently.
> > 
> > Note that I'm not saying this has to be reposted.. I think I can pull
> > off the rmap bits for the time being. I'm just suggesting that if a
> > repost is required from this point forward for any of the logical
> > subunits (deps, rmap, reflink, scrub), I'd suggest to post, version and
> > changelog those units independently.
> 
> I'd thought about continuing my old practice of listing which patches
> go with which feature... but then got lazy. :(  Cleanups/rmap/reflink/scrub
> actually are in their own contiguous sections of the patchbomb, though that
> isn't obvious from looking at it.
> 

Yeah, I figured as much. I was able to surmise where the rmap stuff
ends. It's not so clear where the line between cleanups vs.
dependencies is, however, and as hch mentioned, some of that stuff
apparently stands on its own (i.e, can be merged without being blocked
on rmap review/test/dev cycles).

> You ought to be able to pull only as far as the end of the rmap series and
> still have a working XFS.  I only did the intensive testing with the full
> patchset, but the quick xfstests group ran fine with just the rmap pieces.
> 

Ok. I'll probably end up testing more with just the rmap bits.

> Kernel patches:
> ===============
> Cleanups, 1-11
> rmap + dependencies, 12-49
>     Overlapped interval btree, 12-15
>     Deferred operations, 16-22
>     rmap, 23-49

Thanks. I still stand by my previous comment wrt to splitting any
subsequent postings, if necessary, into separate series though. ;)

Brian

> reflink + dependencies, 50-111
>     AG reservations, 50-52
>     refcount btree, 53-68
>     deferred remap, 69-73
>     cow, 74-88
>     reflink, 89-111
> getfsmapx, 112
> scrub, 113-119
> 
> xfsprogs:
> =========
> Cleanups, 1-15
> rmap + deps, 16-70
>     Overlapped interval btree, 16-19
>     Deferred operations, 20-27
>     rmap, 28-70
> reflink + dependencies, 71-135
>     AG reservations, 71-72
>     refcount btree, 73-85
>     deferred remap, 86-90
>     reflink, 91-135
> getfsmapx, 136-138
> scrub, 139-145
> 
> --D
> 
> > 
> > Brian
> > 
> > > _______________________________________________
> > > xfs mailing list
> > > xfs@oss.sgi.com
> > > http://oss.sgi.com/mailman/listinfo/xfs
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index 3b00f7c..fb371a5 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -157,7 +157,8 @@  struct fsxattr {
 	__u32		fsx_extsize;	/* extsize field value (get/set)*/
 	__u32		fsx_nextents;	/* nextents field value (get)	*/
 	__u32		fsx_projid;	/* project identifier (get/set) */
-	unsigned char	fsx_pad[12];
+	__u32		fsx_cowextsize;	/* CoW extsize field value (get/set)*/
+	unsigned char	fsx_pad[8];
 };
 
 /*
@@ -178,6 +179,8 @@  struct fsxattr {
 #define FS_XFLAG_NODEFRAG	0x00002000	/* do not defragment */
 #define FS_XFLAG_FILESTREAM	0x00004000	/* use filestream allocator */
 #define FS_XFLAG_DAX		0x00008000	/* use DAX for IO */
+#define FS_XFLAG_REFLINK	0x00010000	/* file is reflinked */
+#define FS_XFLAG_COWEXTSIZE	0x00020000	/* CoW extent size allocator hint */
 #define FS_XFLAG_HASATTR	0x80000000	/* no DIFLAG for this	*/
 
 /* the read-only stuff doesn't really belong here, but any other place is