An issue with erofsfuse

An issue with erofsfuse

[Igor Eisberg]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

Hey there, getting straight to the point.
Our team is using Debian 10, in which erofs mounting is not supported and
we have no option of updating the kernel, nor do we have sudo permissions
on this server.

Our only choice is to use erofsfuse to mount an Android image (compression
was used on that image), for the sole purpose of extracting its contents to
another folder for processing.
Tried on Debian 10, pop_OS! and even the latest Kubuntu (where native
mounting is supported), but on all of them I could not copy files which are
compressed from the mounted image to another location (ext4 file system).

The error I'm getting is: "Operation not supported (95)"

Notes:
* Only extremely small (< 1 KB) files which are stored uncompressed are
copied successfully.
* Copying works perfectly when mounting the image with "sudo mount" on the
latest Kubuntu, so it has to be something with erofsfuse.

Anything you can do to help resolve this?

Best,
Igor.

[-- Attachment #2: Type: text/html, Size: 1198 bytes --]

Re: An issue with erofsfuse

[Gao Xiang]

Hi Igor,

On Fri, Aug 20, 2021 at 03:34:05PM +0300, Igor Eisberg wrote:
> Hey there, getting straight to the point.
> Our team is using Debian 10, in which erofs mounting is not supported and
> we have no option of updating the kernel, nor do we have sudo permissions
> on this server.
> 
> Our only choice is to use erofsfuse to mount an Android image (compression
> was used on that image), for the sole purpose of extracting its contents to
> another folder for processing.
> Tried on Debian 10, pop_OS! and even the latest Kubuntu (where native
> mounting is supported), but on all of them I could not copy files which are
> compressed from the mounted image to another location (ext4 file system).
> 
> The error I'm getting is: "Operation not supported (95)"
> 

Thanks for your feedback.

Could you check if lz4 was built-in when building erofsfuse? I guess
that is the reason (lack of lz4 support builtin).

If not, could you add -d to erofsfuse when starting up?

Thanks,
Gao Xiang

> Notes:
> * Only extremely small (< 1 KB) files which are stored uncompressed are
> copied successfully.
> * Copying works perfectly when mounting the image with "sudo mount" on the
> latest Kubuntu, so it has to be something with erofsfuse.
> 
> Anything you can do to help resolve this?
> 
> Best,
> Igor.

Re: An issue with erofsfuse

[Igor Eisberg]

[-- Attachment #1: Type: text/plain, Size: 2278 bytes --]

You're quicker than expected, thanks for answering.
Not sure how to check if lz4 was builtin, but considering that erofsfuse is
only about 34.5KB (stripped) I would guess not?
Here's the output of erofsfuse -d (it prints this but never exists back to
shell unless I do Ctrl+C):

erofsfuse 1.3
>
> disk: product.img
>
> mountpoint: product-mnt
>
> dbglevel: 7
>
> FUSE library version: 2.9.9
>
> nullpath_ok: 0
>
> nopath: 0
>
> utime_omit_ok: 0
>
> unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0
>
> INIT: 7.27
>
> flags=0x003ffffb
>
> max_readahead=0x00020000
>
> EROFS: erofsfuse_init() Line[23] Using FUSE protocol 7.27
>
>    INIT: 7.19
>
>    flags=0x00000011
>
>    max_readahead=0x00020000
>
>    max_write=0x00020000
>
>    max_background=0
>
>    congestion_threshold=0
>
>    unique: 1, success, outsize: 40
>
>
On Fri, 20 Aug 2021 at 15:49, Gao Xiang <xiang@kernel.org> wrote:

> Hi Igor,
>
> On Fri, Aug 20, 2021 at 03:34:05PM +0300, Igor Eisberg wrote:
> > Hey there, getting straight to the point.
> > Our team is using Debian 10, in which erofs mounting is not supported and
> > we have no option of updating the kernel, nor do we have sudo permissions
> > on this server.
> >
> > Our only choice is to use erofsfuse to mount an Android image
> (compression
> > was used on that image), for the sole purpose of extracting its contents
> to
> > another folder for processing.
> > Tried on Debian 10, pop_OS! and even the latest Kubuntu (where native
> > mounting is supported), but on all of them I could not copy files which
> are
> > compressed from the mounted image to another location (ext4 file system).
> >
> > The error I'm getting is: "Operation not supported (95)"
> >
>
> Thanks for your feedback.
>
> Could you check if lz4 was built-in when building erofsfuse? I guess
> that is the reason (lack of lz4 support builtin).
>
> If not, could you add -d to erofsfuse when starting up?
>
> Thanks,
> Gao Xiang
>
> > Notes:
> > * Only extremely small (< 1 KB) files which are stored uncompressed are
> > copied successfully.
> > * Copying works perfectly when mounting the image with "sudo mount" on
> the
> > latest Kubuntu, so it has to be something with erofsfuse.
> >
> > Anything you can do to help resolve this?
> >
> > Best,
> > Igor.
>

[-- Attachment #2: Type: text/html, Size: 5560 bytes --]

Re: An issue with erofsfuse

[Huang Jianan]

[-- Attachment #1: Type: text/plain, Size: 2965 bytes --]

On 2021/8/20 21:16, Igor Eisberg wrote:
> You're quicker than expected, thanks for answering.
> Not sure how to check if lz4 was builtin, but considering that 
> erofsfuse is only about 34.5KB (stripped) I would guess not?
> Here's the output of erofsfuse -d (it prints this but never exists 
> back to shell unless I do Ctrl+C):
>
You can use lz4 --version to check the version of lz4 library, I have 
got the same error on the old version, better to use the version above 
1.9.2.

If the problem still exists, you can use the -d --dbglevel=9 option, and 
then perform a read to get the detailed log.

Thanks,

Jianan

>         erofsfuse 1.3
>
>         disk: product.img
>
>         mountpoint: product-mnt
>
>         dbglevel: 7
>
>         FUSE library version: 2.9.9
>
>         nullpath_ok: 0
>
>         nopath: 0
>
>         utime_omit_ok: 0
>
>         unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0
>
>         INIT: 7.27
>
>         flags=0x003ffffb
>
>         max_readahead=0x00020000
>
>         EROFS: erofsfuse_init() Line[23] Using FUSE protocol 7.27
>
>            INIT: 7.19
>
>            flags=0x00000011
>
>          max_readahead=0x00020000
>
>            max_write=0x00020000
>
>            max_background=0
>
>          congestion_threshold=0
>
>            unique: 1, success, outsize: 40
>
>
> On Fri, 20 Aug 2021 at 15:49, Gao Xiang <xiang@kernel.org> wrote:
>
>     Hi Igor,
>
>     On Fri, Aug 20, 2021 at 03:34:05PM +0300, Igor Eisberg wrote:
>     > Hey there, getting straight to the point.
>     > Our team is using Debian 10, in which erofs mounting is not
>     supported and
>     > we have no option of updating the kernel, nor do we have sudo
>     permissions
>     > on this server.
>     >
>     > Our only choice is to use erofsfuse to mount an Android image
>     (compression
>     > was used on that image), for the sole purpose of extracting its
>     contents to
>     > another folder for processing.
>     > Tried on Debian 10, pop_OS! and even the latest Kubuntu (where
>     native
>     > mounting is supported), but on all of them I could not copy
>     files which are
>     > compressed from the mounted image to another location (ext4 file
>     system).
>     >
>     > The error I'm getting is: "Operation not supported (95)"
>     >
>
>     Thanks for your feedback.
>
>     Could you check if lz4 was built-in when building erofsfuse? I guess
>     that is the reason (lack of lz4 support builtin).
>
>     If not, could you add -d to erofsfuse when starting up?
>
>     Thanks,
>     Gao Xiang
>
>     > Notes:
>     > * Only extremely small (< 1 KB) files which are stored
>     uncompressed are
>     > copied successfully.
>     > * Copying works perfectly when mounting the image with "sudo
>     mount" on the
>     > latest Kubuntu, so it has to be something with erofsfuse.
>     >
>     > Anything you can do to help resolve this?
>     >
>     > Best,
>     > Igor.
>

[-- Attachment #2: Type: text/html, Size: 8113 bytes --]

Re: An issue with erofsfuse

[Gao Xiang]

On Fri, Aug 20, 2021 at 04:16:20PM +0300, Igor Eisberg wrote:
> You're quicker than expected, thanks for answering.
> Not sure how to check if lz4 was builtin, but considering that erofsfuse is
> only about 34.5KB (stripped) I would guess not?
> Here's the output of erofsfuse -d (it prints this but never exists back to
> shell unless I do Ctrl+C):

Yeah, it will run erofsfuse in foreground, and you need to access the
erofs compressed files, and then check the printed result.

But I think there is a easier way to check if lz4 was linked, just type
ldd <your erofsfuse program>

if lz4 was linked, it will print some message like below:
	linux-vdso.so.1 (0x00007ffee176e000)
	libfuse.so.2 =&gt; /lib/x86_64-linux-gnu/libfuse.so.2 (0x00007f8e21f24000)
	liblz4.so.1 =&gt; /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f8e21f01000)
	libpthread.so.0 =&gt; /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8e21ee0000)
	libc.so.6 =&gt; /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8e21d1f000)
	libdl.so.2 =&gt; /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8e21d1a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f8e21f91000)

Thanks,
Gao Xiang

> 
> erofsfuse 1.3
> >
> > disk: product.img
> >
> > mountpoint: product-mnt
> >
> > dbglevel: 7
> >
> > FUSE library version: 2.9.9
> >
> > nullpath_ok: 0
> >
> > nopath: 0
> >
> > utime_omit_ok: 0
> >
> > unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0
> >
> > INIT: 7.27
> >
> > flags=0x003ffffb
> >
> > max_readahead=0x00020000
> >
> > EROFS: erofsfuse_init() Line[23] Using FUSE protocol 7.27
> >
> >    INIT: 7.19
> >
> >    flags=0x00000011
> >
> >    max_readahead=0x00020000
> >
> >    max_write=0x00020000
> >
> >    max_background=0
> >
> >    congestion_threshold=0
> >
> >    unique: 1, success, outsize: 40
> >
> >
> On Fri, 20 Aug 2021 at 15:49, Gao Xiang <xiang@kernel.org> wrote:
> 
> > Hi Igor,
> >
> > On Fri, Aug 20, 2021 at 03:34:05PM +0300, Igor Eisberg wrote:
> > > Hey there, getting straight to the point.
> > > Our team is using Debian 10, in which erofs mounting is not supported and
> > > we have no option of updating the kernel, nor do we have sudo permissions
> > > on this server.
> > >
> > > Our only choice is to use erofsfuse to mount an Android image
> > (compression
> > > was used on that image), for the sole purpose of extracting its contents
> > to
> > > another folder for processing.
> > > Tried on Debian 10, pop_OS! and even the latest Kubuntu (where native
> > > mounting is supported), but on all of them I could not copy files which
> > are
> > > compressed from the mounted image to another location (ext4 file system).
> > >
> > > The error I'm getting is: "Operation not supported (95)"
> > >
> >
> > Thanks for your feedback.
> >
> > Could you check if lz4 was built-in when building erofsfuse? I guess
> > that is the reason (lack of lz4 support builtin).
> >
> > If not, could you add -d to erofsfuse when starting up?
> >
> > Thanks,
> > Gao Xiang
> >
> > > Notes:
> > > * Only extremely small (< 1 KB) files which are stored uncompressed are
> > > copied successfully.
> > > * Copying works perfectly when mounting the image with "sudo mount" on
> > the
> > > latest Kubuntu, so it has to be something with erofsfuse.
> > >
> > > Anything you can do to help resolve this?
> > >
> > > Best,
> > > Igor.
> >

Re: An issue with erofsfuse

[Igor Eisberg]

[-- Attachment #1: Type: text/plain, Size: 4456 bytes --]

You're right, this is definitely what's missing:

>       linux-vdso.so.1 (0x00007ffeb2163000)
>        libfuse.so.2 => /lib/x86_64-linux-gnu/libfuse.so.2
> (0x00007ffb2d6b7000)
>        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x00007ffb2d694000)
>        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffb2d4a3000)
>        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ffb2d49d000)
>        /lib64/ld-linux-x86-64.so.2 (0x00007ffb2d728000)
>

And actually when running configure, I notice this:

> checking lz4.h usability... no
> checking lz4.h presence... no
> checking for lz4.h... no
>

Not sure what I'm missing here though...

$ apt list --installed | grep lz4
> liblz4-1/now 1.9.3-2 amd64 [installed,local]
> lz4/now 1.9.3-2 amd64 [installed,local]
>

On Fri, 20 Aug 2021 at 16:27, Gao Xiang <xiang@kernel.org> wrote:

> On Fri, Aug 20, 2021 at 04:16:20PM +0300, Igor Eisberg wrote:
> > You're quicker than expected, thanks for answering.
> > Not sure how to check if lz4 was builtin, but considering that erofsfuse
> is
> > only about 34.5KB (stripped) I would guess not?
> > Here's the output of erofsfuse -d (it prints this but never exists back
> to
> > shell unless I do Ctrl+C):
>
> Yeah, it will run erofsfuse in foreground, and you need to access the
> erofs compressed files, and then check the printed result.
>
> But I think there is a easier way to check if lz4 was linked, just type
> ldd <your erofsfuse program>
>
> if lz4 was linked, it will print some message like below:
>         linux-vdso.so.1 (0x00007ffee176e000)
>         libfuse.so.2 =&gt; /lib/x86_64-linux-gnu/libfuse.so.2
> (0x00007f8e21f24000)
>         liblz4.so.1 =&gt; /lib/x86_64-linux-gnu/liblz4.so.1
> (0x00007f8e21f01000)
>         libpthread.so.0 =&gt; /lib/x86_64-linux-gnu/libpthread.so.0
> (0x00007f8e21ee0000)
>         libc.so.6 =&gt; /lib/x86_64-linux-gnu/libc.so.6
> (0x00007f8e21d1f000)
>         libdl.so.2 =&gt; /lib/x86_64-linux-gnu/libdl.so.2
> (0x00007f8e21d1a000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007f8e21f91000)
>
> Thanks,
> Gao Xiang
>
> >
> > erofsfuse 1.3
> > >
> > > disk: product.img
> > >
> > > mountpoint: product-mnt
> > >
> > > dbglevel: 7
> > >
> > > FUSE library version: 2.9.9
> > >
> > > nullpath_ok: 0
> > >
> > > nopath: 0
> > >
> > > utime_omit_ok: 0
> > >
> > > unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0
> > >
> > > INIT: 7.27
> > >
> > > flags=0x003ffffb
> > >
> > > max_readahead=0x00020000
> > >
> > > EROFS: erofsfuse_init() Line[23] Using FUSE protocol 7.27
> > >
> > >    INIT: 7.19
> > >
> > >    flags=0x00000011
> > >
> > >    max_readahead=0x00020000
> > >
> > >    max_write=0x00020000
> > >
> > >    max_background=0
> > >
> > >    congestion_threshold=0
> > >
> > >    unique: 1, success, outsize: 40
> > >
> > >
> > On Fri, 20 Aug 2021 at 15:49, Gao Xiang <xiang@kernel.org> wrote:
> >
> > > Hi Igor,
> > >
> > > On Fri, Aug 20, 2021 at 03:34:05PM +0300, Igor Eisberg wrote:
> > > > Hey there, getting straight to the point.
> > > > Our team is using Debian 10, in which erofs mounting is not
> supported and
> > > > we have no option of updating the kernel, nor do we have sudo
> permissions
> > > > on this server.
> > > >
> > > > Our only choice is to use erofsfuse to mount an Android image
> > > (compression
> > > > was used on that image), for the sole purpose of extracting its
> contents
> > > to
> > > > another folder for processing.
> > > > Tried on Debian 10, pop_OS! and even the latest Kubuntu (where native
> > > > mounting is supported), but on all of them I could not copy files
> which
> > > are
> > > > compressed from the mounted image to another location (ext4 file
> system).
> > > >
> > > > The error I'm getting is: "Operation not supported (95)"
> > > >
> > >
> > > Thanks for your feedback.
> > >
> > > Could you check if lz4 was built-in when building erofsfuse? I guess
> > > that is the reason (lack of lz4 support builtin).
> > >
> > > If not, could you add -d to erofsfuse when starting up?
> > >
> > > Thanks,
> > > Gao Xiang
> > >
> > > > Notes:
> > > > * Only extremely small (< 1 KB) files which are stored uncompressed
> are
> > > > copied successfully.
> > > > * Copying works perfectly when mounting the image with "sudo mount"
> on
> > > the
> > > > latest Kubuntu, so it has to be something with erofsfuse.
> > > >
> > > > Anything you can do to help resolve this?
> > > >
> > > > Best,
> > > > Igor.
> > >
>

[-- Attachment #2: Type: text/html, Size: 7078 bytes --]

Re: An issue with erofsfuse

[Gao Xiang]

On Fri, Aug 20, 2021 at 04:35:52PM +0300, Igor Eisberg wrote:
> You're right, this is definitely what's missing:
> 
> >       linux-vdso.so.1 (0x00007ffeb2163000)
> >        libfuse.so.2 => /lib/x86_64-linux-gnu/libfuse.so.2
> > (0x00007ffb2d6b7000)
> >        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> > (0x00007ffb2d694000)
> >        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffb2d4a3000)
> >        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ffb2d49d000)
> >        /lib64/ld-linux-x86-64.so.2 (0x00007ffb2d728000)
> >
> 
> And actually when running configure, I notice this:
> 
> > checking lz4.h usability... no
> > checking lz4.h presence... no
> > checking for lz4.h... no
> >
> 
> Not sure what I'm missing here though...

Maybe "sudo apt install liblz4-dev" for debian.

(Anyway, I may need to add another erofsfuse package for Debian sid,
 I may seek some time to do this.)

Thanks,
Gao Xiang

> 
> $ apt list --installed | grep lz4
> > liblz4-1/now 1.9.3-2 amd64 [installed,local]
> > lz4/now 1.9.3-2 amd64 [installed,local]
> >
> 

Re: An issue with erofsfuse

[Igor Eisberg]

[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]

Ah yes, silly me, got liblz4-1 confused with liblz4-dev, had to download
the 1.9.3 *.deb packages manually cause apt-get is pushing 1.8.3.
Now everything is working top-notch.

Regarding mkfs.erofs, I know it can take file_contexts, but how should we
handle fs_config, if it's even necessary?

On Fri, 20 Aug 2021 at 16:43, Gao Xiang <xiang@kernel.org> wrote:

> On Fri, Aug 20, 2021 at 04:35:52PM +0300, Igor Eisberg wrote:
> > You're right, this is definitely what's missing:
> >
> > >       linux-vdso.so.1 (0x00007ffeb2163000)
> > >        libfuse.so.2 => /lib/x86_64-linux-gnu/libfuse.so.2
> > > (0x00007ffb2d6b7000)
> > >        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> > > (0x00007ffb2d694000)
> > >        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> (0x00007ffb2d4a3000)
> > >        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
> (0x00007ffb2d49d000)
> > >        /lib64/ld-linux-x86-64.so.2 (0x00007ffb2d728000)
> > >
> >
> > And actually when running configure, I notice this:
> >
> > > checking lz4.h usability... no
> > > checking lz4.h presence... no
> > > checking for lz4.h... no
> > >
> >
> > Not sure what I'm missing here though...
>
> Maybe "sudo apt install liblz4-dev" for debian.
>
> (Anyway, I may need to add another erofsfuse package for Debian sid,
>  I may seek some time to do this.)
>
> Thanks,
> Gao Xiang
>
> >
> > $ apt list --installed | grep lz4
> > > liblz4-1/now 1.9.3-2 amd64 [installed,local]
> > > lz4/now 1.9.3-2 amd64 [installed,local]
> > >
> >
>

[-- Attachment #2: Type: text/html, Size: 2188 bytes --]

Re: An issue with erofsfuse

[Gao Xiang]

On Fri, Aug 20, 2021 at 04:58:38PM +0300, Igor Eisberg wrote:
> Ah yes, silly me, got liblz4-1 confused with liblz4-dev, had to download
> the 1.9.3 *.deb packages manually cause apt-get is pushing 1.8.3.
> Now everything is working top-notch.
> 
> Regarding mkfs.erofs, I know it can take file_contexts, but how should we
> handle fs_config, if it's even necessary?

I think you need mkfs.erofs from latest AOSP tree, we don't directly
enable fs_config for generic Linux build.

Thanks,
Gao Xiang

Re: An issue with erofsfuse

[Igor Eisberg]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

Ah you actually do have an option for that, I was looking at some old docs
probably.

" --fs-config-file=X    X=fs_config file\n"
>

Mate, I thank you sincerely, may the file system prosper.
Have a great weekend!

On Fri, 20 Aug 2021 at 17:06, Gao Xiang <xiang@kernel.org> wrote:

> On Fri, Aug 20, 2021 at 04:58:38PM +0300, Igor Eisberg wrote:
> > Ah yes, silly me, got liblz4-1 confused with liblz4-dev, had to download
> > the 1.9.3 *.deb packages manually cause apt-get is pushing 1.8.3.
> > Now everything is working top-notch.
> >
> > Regarding mkfs.erofs, I know it can take file_contexts, but how should we
> > handle fs_config, if it's even necessary?
>
> I think you need mkfs.erofs from latest AOSP tree, we don't directly
> enable fs_config for generic Linux build.
>
> Thanks,
> Gao Xiang
>

[-- Attachment #2: Type: text/html, Size: 1364 bytes --]