mkfs.erofs fails (failed to build shared xattrs, err 61)

[Gael Donval]

On Tue, 2024-03-12 at 20:43 +0800, Gao Xiang wrote:
> 
> 
> On 2024/3/12 20:01, Gael Donval wrote:
> > On Tue, 2024-03-12 at 19:37 +0800, Gao Xiang wrote:
> > > 
> > > 
> > > On 2024/3/12 19:07, Gael Donval wrote:
> > > > > On 2024/3/12 18:44, Gao Xiang wrote:
> > > > > > Hi Gael,
> > > > > > 
> > > > > > On 2024/3/12 17:57, Gael Donval wrote:
> > > > > > > Dear list,
> > > > > > > 
> > > > > > >       $ mkdir foo && touch foo/bar && mkfs.erofs
> > > > > > > foo.erofs.img
> > > > > > > foo
> > > > > > >       mkfs.erofs 1.7.1
> > > > > > >       <E> erofs: failed to build shared xattrs: [Error
> > > > > > > 61] No
> > > > > > > data
> > > > > > > available
> > > > > > >       <E> erofs:     Could not format the device : [Error
> > > > > > > 61]
> > > > > > > No
> > > > > > > data available
> > > > > > > That is at a location backed by BTRFS (btrfs-progs
> > > > > > > v6.7.1) on
> > > > > > > kernel 6.8.0.
> > > > > > > 
> > > > > > > If I use a TMPFS-supported folder instead all goes well.
> > > > > > > 
> > > > > > > 
> > > > > > > Of course (NB "-x-1"),
> > > > > > > 
> > > > > > >       $ mkdir foo && touch foo/bar && mkfs.erofs -x-1
> > > > > > > foo.erofs.img
> > > > > > > foo
> > > > > > > 
> > > > > > > also works but is not how mkfs.erofs is meant to work in
> > > > > > > the
> > > > > > > general case.
> > > > > > 
> > > > > > Thanks for your feedback.
> > > > > > 
> > > > > > Currently I don't have some BTRFS environment, I could set
> > > > > > up
> > > > > > one
> > > > > > later.
> > > > > > Yet in parallel could you provide a full message of
> > > > > > "strace mkfs.erofs -x-1 foo.erofs.img foo" on BTRFS too?
> > > > > 
> > > > > sorry, I meant "strace mkfs.erofs foo.erofs.img foo"
> > > > 
> > > > Hi,
> > > > 
> > > > Here it is.
> > > > 
> > > 
> > > The problem here is that BTRFS could extract their internal
> > > xattrs ("inode properties") in their own namespace which
> > > don't belong to the original file itself like:
> > > 
> > > XATTR_BTRFS_PREFIX "compression" -> btrfs.compression = zstd
> > > 
> > > I think I need to introduce something to formally ignore
> > > these xattrs like: `--xattrs-exclude=pattern`:
> > > https://urldefense.com/v3/__https://www.gnu.org/software/tar/manual/html_node/Extended-File-Attributes.html__;!!PDiH4ENfjr2_Jw!Dqu_tH2zT_TKEhHNi2CZToYlmYFeZayWE1BQVQjZBZq4egjYS1bAVS7BasQJ9BETJoVINPEB-p06y7izIUmWk-2VnofOQZwLrw$
> > >   [gnu[.]org]
> > 
> > I think that could work but a mode where EROFS keep the XATTRS it
> > recognises and ignore the ones it doesn't would probably prove
> > useful
> > in the general case.
> > 
> > I would suggest a --strict-xattrs mode behaving like it does today,
> > requiring explicit --xattrs-exclude to whitelist XATTRS.
> > 
> > The default would be a relaxed mode where ignored XATTRS are
> > reported
> > on stderr at INFO level. Would that make sense and be alright?
> 
> Yes, but that needs a new version (maybe erofs-utils 1.8) though.

Of course!

> 
> Also I'm not sure how tar --xattrs works for "btrfs.compression",
> does it also work in a relaxed mode? Could you give more inputs
> & tries with "tar --xattrs"?

Tar just stores XATTRS as their own field. When I 

   $ tar --xattrs -cf foo.tar foo

and inspect the tar file it appears XATTRS are stored as arbitrary
SCHILY attributes:

   ./PaxHeaders/foo0000644000000000000000000000020114574033222010776
   xustar0030 mtime=1710241426.458097911
   30 atime=1710241426.458097911
   30 ctime=1710241426.458097911
   39 SCHILY.xattr.btrfs.compression=zstd
   foo/0000755000175000017500000000000014574033222011551
   5ustar00gdonvalgdonval
   [...]

So tar blindly serializes everything.


> 
> > 
> > Is there anything the BTRFS people could do to make their FS easier
> > to
> > work with?
> 
> Nope, I think it's unrelated to BTRFS but such xattrs are almost
> meaningless for EROFS to keep (since they are their own xattrs.)

Ah that's interesting.

I suspect that in this instance the xattrs would not be useful at all
but other components like SELinux uses xattrs to perform MAC and who
knows what other xattrs-based schemes exist out there...

Would it make sense then to do what tar does and blindly serialize (and
expose) everything and provide a --xattrs-exclude=pattern in case
people want something more fine-grained?

The only main problem currently is that erofs tries to be smart about
xattrs and errors out when it does not know about something. It should
really be more graceful.

Thanks,
Gaël


> 
> Thanks,
> Gao Xiang
> 
> > 
> > Gaël
> > 
> > > 
> > > Thanks,
> > > Gao Xiang
> > > 
> > > > Thanks for your help,
> > > > Gaël
> > > > 
> > > > 
> >