Re: mkfs.erofs fails (failed to build shared xattrs, err 61)
> > If there is harm, mkfs.erofs should strip anything that it does not > > support without producing an error. > > > > Either way, there should be no error. :) > > Fair enough, I think I will do this for erofs-utils 1.8, but I tend > to consider unsupported xattr namespaces as warn messages, users > could silence these with proper '-d' message levels. I'm absolutely fine with that as long as mkfs.erofs goes through with generating the FS (it does not generate anything right now) and returns success to the shell. Thanks a lot for your help, Gaël > > Thanks, > Gao Xiang
Re: mkfs.erofs fails (failed to build shared xattrs, err 61)
On 2024/3/12 23:29, Gael Donval wrote: On Tue, 2024-03-12 at 22:15 +0800, Gao Xiang wrote: On 2024/3/12 21:14, Gael Donval wrote: On Tue, 2024-03-12 at 20:43 +0800, Gao Xiang wrote: ... 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/foo6440020114574033222010776 xustar0030 mtime=1710241426.458097911 30 atime=1710241426.458097911 30 ctime=1710241426.458097911 39 SCHILY.xattr.btrfs.compression=zstd foo/75500017517514574033222011551 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... EROFS will keep common xattrs like selinux, but EROFS doesn't keep btrfs. namespace (or other arbitrary xattr namespaces) like other filesystems like ext4, xfs, f2fs, squashfs, etc. EROFS only supports "user.", "trusted." and some "system." domains. In other words, If EROFS has its own xattr namespace, I think other fses won't support "erofs." too, also see: https://urldefense.com/v3/__https://lore.kernel.org/r/20230420092739.75464-1-o451686892@gmail.com__;!!PDiH4ENfjr2_Jw!BWdmKT7HAVU-ujqneKbEcblL0CJC9FhQ-MzikSN038KjlQ7HQqdbv1GpOtpZsBRAoW538RPHVpH3-kL7C5DrJV1lzJbQ_uScdQ$ [lore[.]kernel[.]org] Because that is simple, you don't even know if the content in some arbitrary namespace is static or dynamic. Or if it has some security issue to keep them. I don't think supporting 3rd-party FS is the question here at all. If `btrfs.compression=zstd` is set, I don't expect erofs to do anything about it. No support. No understanding of what it is about even. Just that there is metadata there erofs ignores. For `btrfs.compression=zstd`, yes, but for many many other unknown xattrs, that is no. And since EROFS can be directly mounted, it's not a good idea to show special xattrs owned by other filesystems. The real question is more: does it matter, security-wise, if `btrfs.compression=zstd` is added as metadata (just like it is added in tar)? If there is no harm, there could be an argument to keep them as pure metadata (that erofs does NOT act on! no support). You could try to extract this to ext4/xfs. I guess `tar` may print something, but I don't know. If there is harm, mkfs.erofs should strip anything that it does not support without producing an error. Either way, there should be no error. :) Fair enough, I think I will do this for erofs-utils 1.8, but I tend to consider unsupported xattr namespaces as warn messages, users could silence these with proper '-d' message levels. Thanks, Gao Xiang
Re: mkfs.erofs fails (failed to build shared xattrs, err 61)
On Tue, 2024-03-12 at 22:15 +0800, Gao Xiang wrote: > > > On 2024/3/12 21:14, Gael Donval wrote: > > On Tue, 2024-03-12 at 20:43 +0800, Gao Xiang wrote: > > > > > ... > > > > 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/foo6440020114574033222010776 > > xustar0030 mtime=1710241426.458097911 > > 30 atime=1710241426.458097911 > > 30 ctime=1710241426.458097911 > > 39 SCHILY.xattr.btrfs.compression=zstd > > foo/75500017517514574033222011551 > > 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... > > EROFS will keep common xattrs like selinux, but EROFS doesn't keep > btrfs. namespace (or other arbitrary xattr namespaces) like other > filesystems like ext4, xfs, f2fs, squashfs, etc. EROFS only supports > "user.", "trusted." and some "system." domains. In other words, If > EROFS has its own xattr namespace, I think other fses won't support > "erofs." too, also see: > > https://urldefense.com/v3/__https://lore.kernel.org/r/20230420092739.75464-1-o451686892@gmail.com__;!!PDiH4ENfjr2_Jw!BWdmKT7HAVU-ujqneKbEcblL0CJC9FhQ-MzikSN038KjlQ7HQqdbv1GpOtpZsBRAoW538RPHVpH3-kL7C5DrJV1lzJbQ_uScdQ$ > [lore[.]kernel[.]org] > > Because that is simple, you don't even know if the content in some > arbitrary namespace is static or dynamic. Or if it has some security > issue to keep them. I don't think supporting 3rd-party FS is the question here at all. If `btrfs.compression=zstd` is set, I don't expect erofs to do anything about it. No support. No understanding of what it is about even. Just that there is metadata there erofs ignores. The real question is more: does it matter, security-wise, if `btrfs.compression=zstd` is added as metadata (just like it is added in tar)? If there is no harm, there could be an argument to keep them as pure metadata (that erofs does NOT act on! no support). If there is harm, mkfs.erofs should strip anything that it does not support without producing an error. Either way, there should be no error. :) Gaël > > > > > 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? > > As I said above. > > Thanks, > Gao Xiang > > > > > 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 > > > > > > > > > > > > > > > > > >
Re: mkfs.erofs fails (failed to build shared xattrs, err 61)
On 2024/3/12 21:14, Gael Donval wrote: On Tue, 2024-03-12 at 20:43 +0800, Gao Xiang wrote: ... 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/foo6440020114574033222010776 xustar0030 mtime=1710241426.458097911 30 atime=1710241426.458097911 30 ctime=1710241426.458097911 39 SCHILY.xattr.btrfs.compression=zstd foo/75500017517514574033222011551 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... EROFS will keep common xattrs like selinux, but EROFS doesn't keep btrfs. namespace (or other arbitrary xattr namespaces) like other filesystems like ext4, xfs, f2fs, squashfs, etc. EROFS only supports "user.", "trusted." and some "system." domains. In other words, If EROFS has its own xattr namespace, I think other fses won't support "erofs." too, also see: https://lore.kernel.org/r/20230420092739.75464-1-o451686...@gmail.com Because that is simple, you don't even know if the content in some arbitrary namespace is static or dynamic. Or if it has some security issue to keep them. 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? As I said above. Thanks, Gao Xiang 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
Re: mkfs.erofs fails (failed to build shared xattrs, err 61)
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
> > > > > > > erofs: failed to build shared xattrs: [Error
> > > > > > > 61] No
> > > > > > > data
> > > > > > > available
> > > > > > > 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/foo6440020114574033222010776
xustar0030 mtime=1710241426.458097911
30 atime=1710241426.458097911
30 ctime=1710241426.458097911
39 SCHILY.xattr.btrfs.compression=zstd
foo/75500017517514574033222011551
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
> > > >
> > > >
> >
Re: mkfs.erofs fails (failed to build shared xattrs, err 61)
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
erofs: failed to build shared xattrs: [Error 61] No
data
available
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.
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"?
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.)
Thanks,
Gao Xiang
Gaël
Thanks,
Gao Xiang
Thanks for your help,
Gaël
Re: mkfs.erofs fails (failed to build shared xattrs, err 61)
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
> > > > > erofs: failed to build shared xattrs: [Error 61] No
> > > > > data
> > > > > available
> > > > > 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?
Is there anything the BTRFS people could do to make their FS easier to
work with?
Gaël
>
> Thanks,
> Gao Xiang
>
> > Thanks for your help,
> > Gaël
> >
> >
Re: mkfs.erofs fails (failed to build shared xattrs, err 61)
On 2024/3/12 19:37, 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
erofs: failed to build shared xattrs: [Error 61] No data
available
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://www.gnu.org/software/tar/manual/html_node/Extended-File-Attributes.html
BTW, as for erofs-utils 1.7.1, you may use
tar c --xattrs-exclude="btrfs.*" foo | mkfs.erofs --tar=f 111.erofs
as a workaround. I think it will work.
Thanks,
Gao Xiang
Re: mkfs.erofs fails (failed to build shared xattrs, err 61)
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
erofs: failed to build shared xattrs: [Error 61] No data
available
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://www.gnu.org/software/tar/manual/html_node/Extended-File-Attributes.html
Thanks,
Gao Xiang
Thanks for your help,
Gaël
Re: mkfs.erofs fails (failed to build shared xattrs, err 61)
> 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
> > > erofs: failed to build shared xattrs: [Error 61] No data
> > > available
> > > 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.
Thanks for your help,
Gaël
>
> Thanks,
> Gao Xiang
>
> >
> > Thanks,
> > Gao Xiang
> >
> > >
> > > Kind regards,
> > > Gaël
execve("/usr/bin/mkfs.erofs", ["mkfs.erofs", "foo.erofs.img", "foo"],
0x7ffd4e2e1d20 /* 49 vars */) = 0
brk(NULL) = 0x5a8b85317000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=143655, ...}) = 0
mmap(NULL, 143655, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7293c7817000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/libuuid.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=30808, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7293c7815000
mmap(NULL, 32832, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7293c780c000
mmap(0x7293c780e000, 16384, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7293c780e000
mmap(0x7293c7812000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x6000) = 0x7293c7812000
mmap(0x7293c7813000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7293c7813000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/liblz4.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=145280, ...}) = 0
mmap(NULL, 147472, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7293c77e7000
mmap(0x7293c77ea000, 118784, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7293c77ea000
mmap(0x7293c7807000, 12288, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x2) = 0x7293c7807000
mmap(0x7293c780a000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7293c780a000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/liblzma.so.5", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=206872, ...}) = 0
mmap(NULL, 204816, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7293c77b4000
mmap(0x7293c77b7000, 139264, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7293c77b7000
mmap(0x7293c77d9000, 49152, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x25000) = 0x7293c77d9000
mmap(0x7293c77e5000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x31000) = 0x7293c77e5000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=100296, ...}) = 0
mmap(NULL, 102416, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7293c779a000
mmap(0x7293c779d000, 57344, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7293c779d000
mmap(0x7293c77ab000, 28672, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x11000) = 0x7293c77ab000
mmap(0x7293c77b2000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7293c77b2000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220^\2\0\0\0\0\0"...,
832) = 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"...,
784, 64) = 784
fstat(3, {st_mode=S_IFREG|0755, st_size=1948952, ...}) = 0
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"...,
784, 64) = 784
mmap(NULL, 1973104, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7293c75b8000
mmap(0x7293c75dc000, 1421312,
Re: mkfs.erofs fails (failed to build shared xattrs, err 61)
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 erofs: failed to build shared xattrs: [Error 61] No data available 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" Thanks, Gao Xiang Thanks, Gao Xiang Kind regards, Gaël
Re: mkfs.erofs fails (failed to build shared xattrs, err 61)
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 erofs: failed to build shared xattrs: [Error 61] No data available 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? Thanks, Gao Xiang Kind regards, Gaël
