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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Using a virtual machine under the hood to get around these limitations
isn't really an option either. Like I said, this works perfectly fine
if the filesystem's mkfs tool supports populating the filesystem from
a given directory (and btrfs, ext4 already support this with xattrs
and everything). It even works fine with XFS's -p option already,
except when you try to build an image with SELinux enabled as all the
SELinux xattrs are stripped. I would just like to not have to tell my
users to use another filesystem than XFS when they would like to build
images with SELinux enabled unprivileged.

Cheers,

Daan

On Fri, 6 Oct 2023 at 20:57, Darrick J. Wong <djwong@xxxxxxxxxx> wrote:
>
> 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



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux