| Message ID | 1457122300-28514-2-git-send-email-rpeterso@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Mar 04, 2016 at 03:11:37PM -0500, Bob Peterson wrote: > This patch moves the iomap declares from its current location in > exportfs.h to a new iomap.h. This will facilitate future improvements > such as a more efficient fiemap for holey files. Hopefully it will > one day be used for multipage writes as well. Still not a plain move. This adds the fspriv member, but also reduces the size of length which will probably break pnfs exporting in some cases. I have done a plain move in this series: http://thread.gmane.org/gmane.comp.file-systems.xfs.general/73804 might make sense to grab this for both possible tree that could be used for the infrastructure. -- 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
----- Original Message ----- > On Fri, Mar 04, 2016 at 03:11:37PM -0500, Bob Peterson wrote: > > This patch moves the iomap declares from its current location in > > exportfs.h to a new iomap.h. This will facilitate future improvements > > such as a more efficient fiemap for holey files. Hopefully it will > > one day be used for multipage writes as well. > > Still not a plain move. This adds the fspriv member, but also reduces > the size of length which will probably break pnfs exporting in some > cases. > > I have done a plain move in this series: > http://thread.gmane.org/gmane.comp.file-systems.xfs.general/73804 > > might make sense to grab this for both possible tree that could be used > for the infrastructure. > Hi Christoph, Thanks for the link. I'm very pleased to see you're working on the multi-page write and iomap stuff. I'd like to see these patches go forward and I'll build my fiemap stuff off of them. Does it make sense to split the first two vfs-related patches from the others that are more xfs related? I didn't see these patches appear on linux-fsdevel or lkml, so I assume they're only on the xfs list currently? It would be nice to see them on linux-fsdevel, since I'm not subscribed to that xfs list. It would also be useful to get them into some place more central like Al's vfs tree. Regards, Bob Peterson Red Hat File Systems -- 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
On Mon, Mar 28, 2016 at 03:53:04PM -0400, Bob Peterson wrote: > Thanks for the link. I'm very pleased to see you're working on the > multi-page write and iomap stuff. I'd like to see these patches go > forward and I'll build my fiemap stuff off of them. > > Does it make sense to split the first two vfs-related patches from the > others that are more xfs related? I didn't see these patches appear on > linux-fsdevel or lkml, so I assume they're only on the xfs list currently? For now I'm not sure the infrastructure will stay in the generic code or in XFS, so for the first round I just wanted to ask for XFS feedback. -- 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
On Tue, Mar 29, 2016 at 12:40:26AM -0700, Christoph Hellwig wrote: > On Mon, Mar 28, 2016 at 03:53:04PM -0400, Bob Peterson wrote: > > Thanks for the link. I'm very pleased to see you're working on the > > multi-page write and iomap stuff. I'd like to see these patches go > > forward and I'll build my fiemap stuff off of them. > > > > Does it make sense to split the first two vfs-related patches from the > > others that are more xfs related? I didn't see these patches appear on > > linux-fsdevel or lkml, so I assume they're only on the xfs list currently? > > For now I'm not sure the infrastructure will stay in the generic code or > in XFS, so for the first round I just wanted to ask for XFS feedback. QA over the past couple of days has indicatedno regressions, so I'm going to seriously consider the multipage write code for the next XFS merge. I'd be happy to also take fiemap code based on the same iomap interfaces, especially if we can make it a generic, fully functional fiemap implementation and use it in XFS, too. Cheers, Dave.
On Wed, Mar 30, 2016 at 09:20:36AM +1100, Dave Chinner wrote: > > For now I'm not sure the infrastructure will stay in the generic code or > > in XFS, so for the first round I just wanted to ask for XFS feedback. > > QA over the past couple of days has indicatedno regressions, so I'm > going to seriously consider the multipage write code for the next > XFS merge. I'd be happy to also take fiemap code based on the same > iomap interfaces, especially if we can make it a generic, fully > functional fiemap implementation and use it in XFS, too. Ok. Bob, is the code going to be useful for your in gfs2 as-is? I'm torn a bit between adding it to common code because it actually is nicely abstracted and generic, and keepin it in XFS to make future changes easier (getting rid of buffer_heads is the big one here) -- 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
On Wed, Mar 30, 2016 at 09:20:36AM +1100, Dave Chinner wrote: > QA over the past couple of days has indicatedno regressions, so I'm > going to seriously consider the multipage write code for the next > XFS merge. I'd be happy to also take fiemap code based on the same > iomap interfaces, especially if we can make it a generic, fully > functional fiemap implementation and use it in XFS, too. Now that's I've spent some more time with it: it depend on your idea of fully functional. For the actual file data the fiemap implementation is simple and beautiful. But XFS also supports the odd FIEMAP_FLAG_XATTR flags, which makes no sense at all for an fiemap based implementation. -- 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
On Sun, Apr 10, 2016 at 10:15:28AM -0700, Christoph Hellwig wrote: > On Wed, Mar 30, 2016 at 09:20:36AM +1100, Dave Chinner wrote: > > QA over the past couple of days has indicatedno regressions, so I'm > > going to seriously consider the multipage write code for the next > > XFS merge. I'd be happy to also take fiemap code based on the same > > iomap interfaces, especially if we can make it a generic, fully > > functional fiemap implementation and use it in XFS, too. > > Now that's I've spent some more time with it: it depend on your > idea of fully functional. For the actual file data the fiemap > implementation is simple and beautiful. But XFS also supports the > odd FIEMAP_FLAG_XATTR flags, which makes no sense at all for an > fiemap based implementation. In this case, I'd let xfs_vn_fiemap handle that. i.e. if the FIEMAP_FLAG_XATTR is set, run the old code, otherwise call straight into the new generic iomap based code. I'm not sure if how your new code is structured, but n this version __generic_iomap_fiemap() is passed an iomap_get_t callback function. We could simply have XFS pass a different callback function that looks up the attribute fork extent list rather than the data fork extent list to support FIEMAP_FLAG_XATTR appropriately because other than the different initial extent list root it seems to me like the implementation should be identical.... Cheers, Dave.
On Mon, Apr 11, 2016 at 04:17:40PM +1000, Dave Chinner wrote: > In this case, I'd let xfs_vn_fiemap handle that. i.e. if the > FIEMAP_FLAG_XATTR is set, run the old code, otherwise call straight > into the new generic iomap based code. > > I'm not sure if how your new code is structured, but n this version > __generic_iomap_fiemap() is passed an iomap_get_t callback function. > We could simply have XFS pass a different callback function that > looks up the attribute fork extent list rather than the data fork > extent list to support FIEMAP_FLAG_XATTR appropriately because other > than the different initial extent list root it seems to me like the > implementation should be identical.... Providing iomap_ops for the xattr flag look feasily, but currently there is no real testing for it. Only fsstress will call into it at all and doesn't even verify the output. I'll send the iomap implementation and XFS support as RFC, and then you can decide what to do with it. -- 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
On Tue, Apr 12, 2016 at 11:29:40AM -0700, Christoph Hellwig wrote: > On Mon, Apr 11, 2016 at 04:17:40PM +1000, Dave Chinner wrote: > > In this case, I'd let xfs_vn_fiemap handle that. i.e. if the > > FIEMAP_FLAG_XATTR is set, run the old code, otherwise call straight > > into the new generic iomap based code. > > > > I'm not sure if how your new code is structured, but n this version > > __generic_iomap_fiemap() is passed an iomap_get_t callback function. > > We could simply have XFS pass a different callback function that > > looks up the attribute fork extent list rather than the data fork > > extent list to support FIEMAP_FLAG_XATTR appropriately because other > > than the different initial extent list root it seems to me like the > > implementation should be identical.... > > Providing iomap_ops for the xattr flag look feasily, but currently > there is no real testing for it. Only fsstress will call into it > at all and doesn't even verify the output. I'll send the iomap > implementation and XFS support as RFC, and then you can decide what > to do with it. Sure. FWIW, the xfs_io fiemap command is able to query the attribute fork rather than the data fork. I suspect it's not actually used in any regression tests in xfstests, though. Cheers, Dave.
diff --git a/include/linux/exportfs.h b/include/linux/exportfs.h index fa05e04..bb564c1 100644 --- a/include/linux/exportfs.h +++ b/include/linux/exportfs.h @@ -2,6 +2,7 @@ #define LINUX_EXPORTFS_H 1 #include <linux/types.h> +#include <linux/iomap.h> struct dentry; struct iattr; @@ -181,21 +182,6 @@ struct fid { * get_name is not (which is possibly inconsistent) */ -/* types of block ranges for multipage write mappings. */ -#define IOMAP_HOLE 0x01 /* no blocks allocated, need allocation */ -#define IOMAP_DELALLOC 0x02 /* delayed allocation blocks */ -#define IOMAP_MAPPED 0x03 /* blocks allocated @blkno */ -#define IOMAP_UNWRITTEN 0x04 /* blocks allocated @blkno in unwritten state */ - -#define IOMAP_NULL_BLOCK -1LL /* blkno is not valid */ - -struct iomap { - sector_t blkno; /* first sector of mapping */ - loff_t offset; /* file offset of mapping, bytes */ - u64 length; /* length of mapping, bytes */ - int type; /* type of mapping */ -}; - struct export_operations { int (*encode_fh)(struct inode *inode, __u32 *fh, int *max_len, struct inode *parent); diff --git a/include/linux/iomap.h b/include/linux/iomap.h new file mode 100644 index 0000000..161c1c9 --- /dev/null +++ b/include/linux/iomap.h @@ -0,0 +1,20 @@ +#ifndef _IOMAP_H +#define _IOMAP_H + +/* types of block ranges for multipage write mappings. */ +#define IOMAP_HOLE 0x01 /* no blocks allocated, need allocation */ +#define IOMAP_DELALLOC 0x02 /* delayed allocation blocks */ +#define IOMAP_MAPPED 0x03 /* blocks allocated @blkno */ +#define IOMAP_UNWRITTEN 0x04 /* blocks allocated @blkno in unwritten state */ + +#define IOMAP_NULL_BLOCK -1LL /* blkno is not valid */ + +struct iomap { + sector_t blkno; /* first sector of mapping */ + loff_t offset; /* file offset of mapping, bytes */ + ssize_t length; /* length of mapping, bytes */ + int type; /* type of mapping */ + void *priv; /* fs private data associated with map */ +}; + +#endif /* _IOMAP_H */
This patch moves the iomap declares from its current location in exportfs.h to a new iomap.h. This will facilitate future improvements such as a more efficient fiemap for holey files. Hopefully it will one day be used for multipage writes as well. Signed-off-by: Bob Peterson <rpeterso@redhat.com> --- include/linux/exportfs.h | 16 +--------------- include/linux/iomap.h | 20 ++++++++++++++++++++ 2 files changed, 21 insertions(+), 15 deletions(-) create mode 100644 include/linux/iomap.h