On Fri, Oct 06, 2023 at 09:24:50AM +0200, Daan De Meyer wrote: > On Fri, Oct 06, 2023 at 03:36:05PM +1100, Dave Chinner wrote: > > On Thu, Oct 05, 2023 at 09:22:50PM -0700, Darrick J. Wong wrote: > > > On Fri, Oct 06, 2023 at 08:27:54AM +1100, Dave Chinner wrote: > > > > On Thu, Oct 05, 2023 at 10:37:34AM +0200, Daan De Meyer wrote: > > > > > Hi, > > > > > > > > > > It seems using --protofile ignores any extended attributes set on > > > > > source files. I would like to generate an XFS filesystem using > > > > > --protofile where extended attributes are copied from the source files > > > > > into the generated filesystem. Any way to make this happen with > > > > > --protofile? > > > > > > > > mkfs.xfs doesn't have a '--protofile' option. It has a '-p <file>' > > > > option for specifying a protofile - is that what you mean? > > > > > > While we're on the topic, would it also be useful to have a -p switch > > > that would copy the fsxattr options as well? > > > > If protofile support is going to be extended then supporting > > everything that can be read/set through generic kernel interfaces > > would be appropriate... > > > > But I'm not convinced that we should extend protofile support > > because mounting the filesytsem and running rsync, xfs_restore, etc > > can already do all this stuffi with no development work necessary... > > > rsync doesn't support copying the fsxattr data (though it does support > > extended attributes), and iirc xfsdump can only do entire filesystems, > > right? > > Additionally, when populating the filesystem in a regular file, to mount it > we need loop devices and we need to be root. Both of which we want to > avoid. So having an option to do this without mounting the filesystem like > ext4 and btrfs have would be very useful. It doesn't have to be via '-p', I'm > fine with a -d or --rootdir option like the ones that ext4 and btrfs > have as well. <shrug> How about libguestfs then? --D > Cheers, > > Daan > > On Fri, 6 Oct 2023 at 07:04, Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > > > On Fri, Oct 06, 2023 at 03:36:05PM +1100, Dave Chinner wrote: > > > On Thu, Oct 05, 2023 at 09:22:50PM -0700, Darrick J. Wong wrote: > > > > On Fri, Oct 06, 2023 at 08:27:54AM +1100, Dave Chinner wrote: > > > > > On Thu, Oct 05, 2023 at 10:37:34AM +0200, Daan De Meyer wrote: > > > > > > Hi, > > > > > > > > > > > > It seems using --protofile ignores any extended attributes set on > > > > > > source files. I would like to generate an XFS filesystem using > > > > > > --protofile where extended attributes are copied from the source files > > > > > > into the generated filesystem. Any way to make this happen with > > > > > > --protofile? > > > > > > > > > > mkfs.xfs doesn't have a '--protofile' option. It has a '-p <file>' > > > > > option for specifying a protofile - is that what you mean? > > > > > > > > While we're on the topic, would it also be useful to have a -p switch > > > > that would copy the fsxattr options as well? > > > > > > If protofile support is going to be extended then supporting > > > everything that can be read/set through generic kernel interfaces > > > would be appropriate... > > > > > > But I'm not convinced that we should extend protofile support > > > because mounting the filesytsem and running rsync, xfs_restore, etc > > > can already do all this stuffi with no development work necessary... > > > > rsync doesn't support copying the fsxattr data (though it does support > > extended attributes), and iirc xfsdump can only do entire filesystems, > > right? > > > > --D > > > > > Cheers, > > > > > > Dave. > > > -- > > > Dave Chinner > > > david@xxxxxxxxxxxxx
