Compressing filesystems with squashfs and squashmount

[mv]

[Massimo B.]

Really, strace discovered, there is some blocking davfs2 on a slow link...

[Stolz]

I have been using squash_dir successfully for years but last updated has introduced a long delay every time I mount the squashed file systems. The funny thing is if you switch VT while the delay is still on you can access the file system that is supposed to be getting mounted. I saw there are a few reports of this issue in the last months but I didn't see any solution.

Right now I'm using sys-fs/squash_dir-13.6:mv, sys-fs/squashfs-tools-4.3:mv, sys-kernel/aufs-sources-3.17.1, aufs and LZO compression to squash /usr/portage and /usr/src.

Is there any workaround so far?

[Massimo B.]

On one machine I have a squashfs problem:

[mv]

I have no solution to your problem: Perhaps it is bug of the kernel or the squashfs driver in the kernel.

What you can do is to use e.g.

[Massimo B.]

unsquashfs works, but as even new created squashfs are not possible to be mounted, there must be something wrong with the kernel. I already did some make clean and built it again, but the problem remains.
-> topic 1003918
_________________
HP ZBook Power 15.6" G8 i7-11800H|HP EliteDesk 800G1 i7-4790|HP Compaq Pro 6300 i7-3770

[mv]

According to mentioned topic, squashmount-8.7.6 now calls modprobe loop if $modprobe_loop is set (which defaults to true).

[costel78]

Has anyone tried yet squashmount with in-kernel built overlayfs (gentoo-sources-3.18.0) ?
For me it's not working, squashmount list show me mounts points as "bind" and everything it's mounted as read-only.
Config is: @order = ('overlayfs', 'aufs', 'unionfs-fuse', 'unionfs', 'funionfs');
I presume it's because cat /proc/filesystems show nodev overlay instead overlayfs, or other tools are required.
Aufs was working great, but, generally, patches are a little behind latest kernel, since some time now umount times are longer than usual (not due to resquash), and as overlayfs is in mainline I prefer to use it.
_________________
Sorry for my English. I'm still learning this language.

[mv]

[costel78]

[mv]

squashmount-9.0.0 should now support "overlay" of kernel-3.18.

Note that the name "overlay" is now used in squashmount (e.g. in @order or in MOUNT_OVERLAY) to distinguish from "overlayfs" of earlier kernel versions.

[costel78]

That was fast.
Unfortunately, it seems that something is wrong with mount options: workdir and upperdir must reside under the same mount

[mv]

[costel78]

[mv]

[costel78]

You were right. It is working now. My bad by ignoring etc-update.
Comparing to aufs there is no delay at mount or umount.

Thank you very much!
_________________
Sorry for my English. I'm still learning this language.

[Massimo B.]

Hi, now that overlayfs is part of the 3.18 kernel and supported by squashmount as "overlay", is that now the preferred choice? I had unionfs-fuse before and keep it as fallback, but that itself claims to have some performance issues due to userspace fuse compared to kernel solutions.

Some other issue: Back on some machine behind a http proxy I realised that http://overlays.gentoo.org/ is down for a while now and no ETA (look at http://infra-status.gentoo.org/). With your mv overlay being the only important overlay currently for my basic installation I'm lost without that overlay. Is there no other http mirror at least for that single overlay I can add manually to layman? On the github there are no ebuilds. For now I just added the script manually via wget, but like to keep updated by the overlay as usual.
Bad enough that the overlay mirror is down, is there no alternative? There is http://gpo.zugaina.org/ with snapshots but it does not seem to be appropriate for layman or as overlay in general.
_________________
HP ZBook Power 15.6" G8 i7-11800H|HP EliteDesk 800G1 i7-4790|HP Compaq Pro 6300 i7-3770

[mv]

[Massimo B.]

[Massimo B.]

[mv]

With systemd it happens sometimes that filesystems are mounted but actually do not become mounted, at least if some --make-shared is in effect, see e.g. the problem described in the thread concerning systemd-216: mount.

If this happens, squashmount claims to have mounted successfully, but when shutting down squashes the (unmounted, hence usually empty!) directory and fails to umount: Thus, you get horrible failures with data loss in such a case!

With systemd-219 the problem has increased, since systemd now uses the concept that every mounting operation is superpvised by systemd and automatically acts like the starting of an internal unit (e.g. being displayed with systemctl). This is complete inappropriate behaviour for any init system: systemd attempts to play the role of the operating system which it should not do, and fails miserably in this attempt.

Due to all these bugs and idiocies, systemd support in squashmount is now officially dropped: It would not be sane to write dozens of hacks to work around all the breakage which systemd causes by its completely broken concepts.

You may be lucky and squashmount works with systemd for you (it would not be a problem if systemd would not change the behaviour of "mount" itself), but don't expect to get support or that squashmount works around the systemd bugs (including the conceptional bugs, which are the worst ones, of course).

Use a sane init system like openrc!

Edit: Reformulated according to most current information.

[gringo]

[mv]

[gringo]

thanks !

[mv]

Once more: If you do not have a special setup, the combination squashmount+systemd will probably just work.
What is not going to happen is that squashmount will add hacks to workaround the bugs of systemd which cause "mount" to fail in certain situations (e.g. sometimes when mount --make-shared is in effect) without reporting a failure: This is what I meant by "support is dropped".