Re: mkfs.xfs with --protofile does not copy extended attributes into the generated filesystem

["Darrick J. Wong" <djwong@kernel.org>]

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@kernel.org> 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@fromorbit.com