What is the purpose of the new /etc/portage/repo.postsync.d/50-squashmount-gentoo?
It seems to remount (re-compress) the files after sync which seems quite useful (I did a global squashmount remount by nightly cron-job so far).

But in that file there is said:

Quote:

# This file remounts the squashmount mount-point "gentoo" after each syncing
# of the "gentoo" repository.
# Do not use this file if you want to use a mount-point named "gentoo" with
# squashmount without using sync-type = squashdelta

So without squashdelta this should not be used?
Then the mount-point is called gentoo, while my "gentoo" repo is called portage and located as default in /usr/portage.
Then squashdelta was told to be broken and not available anymore, no?

..inofficial mirror but quite up-to-date with less than 1 hour delay.
While having some more local data with .git/ metadata I pay that for having the compact delta sync.
A bare repo with metadata only would not even need squashfs as git already has some zlib compression, but a checkout is still required as portage cannot work on a bare git repo only._________________ppc:PowerBook5,8 15"(1440)-G4/1.67,2G Ram|amd64:HP EliteBook 8560w,i7-2620M,16G Ram|amd64:Acer Z5610 (Core2QuadQ8200),8G Ram|amd64-prefix:OpenSuse
Lila-Theme

What is the purpose of the new /etc/portage/repo.postsync.d/50-squashmount-gentoo?

It is for playing nice with the squashdelta module of portage.

Quote:

It seems to remount (re-compress) the files after sync which seems quite useful

I would not consider it that useful: You loose the advantage that you can no longer see the differences (in the CHANGES directory) and you do no longer have the previous tree (as READONLY) accessible for the few cases that you might want to to roll back.

Quote:

(I did a global squashmount remount by nightly cron-job so far).

It is dangerous to do this by a cron-job: You will run into troubles if a long emerge is still running which might access the tree at the same time. I usually do it after I finished emerge -NaDu @world or do not call it at all - since it will automatically be called when I switch off the machine. Of course, the latter is a bad idea if you usually never switch off the machine...

Quote:

So without squashdelta this should not be used?

With squashdelta, it is necessary, because the tree must be remounted when the .sqfs file was modified. Without squashdelta - if you consider it reasonable, you can resquash, of course, but the advantage is questionable.

Quote:

Then the mount-point is called gentoo, while my "gentoo" repo is called portage and located as default in /usr/portage.

When you switch to squashdelta, you will likely want to have to mount points: One for layman overlays (or perhaps also for local overlay) and one for the gentoo repository. You cannot mix them, since the distributed .sqfs-file only contains the gentoo repository. Since it is not simple to check in the script whether squashdelta was used, the name is used as a heuristic guess whether the user switched to squashdelta...
Of course, you can simply modify the script (after all, it is in a CONFIG_PROTECT directory) to match the name of your repository and/or use other squashmount options. The script is more meant as an example (which usually does not hurt if it is installed by default, unless you use the mount-point "gentoo" for something completely different...)

Quote:

Then squashdelta was told to be broken and not available anymore, no?

squashdelta was the unfortunate victim of an argument between the developers: If I understand correctly, it was removed as a "punishment" for a bad tone. Unfortunately, this "punishment" actually hurts the portage users more than the developers. I hope that the developers will make their mind up after a while and put the module back.

It is dangerous to do this by a cron-job: You will run into troubles if a long emerge is still running which might access the tree at the same time. I usually do it after I finished emerge -NaDu @world or do not call it at all - since it will automatically be called when I switch off the machine. Of course, the latter is a bad idea if you usually never switch off the machine...

It's bad for the machine I never halt, and it is bad for the machines I often halt because usually I stop the machine soon before leaving and a very long shutdown compressing around is annoying then.
Of course I check for running emerge processes in that cron-job:

squashdelta was the unfortunate victim of an argument between the developers: If I understand correctly, it was removed as a "punishment" for a bad tone. Unfortunately, this "punishment" actually hurts the portage users more than the developers. I hope that the developers will make their mind up after a while and put the module back.

Interesting. I will look into squashdelta and how it works if it is back again. I'll see if it has benefits over git as sync-type. If it won't come back as official sync-type... then I would rather forget about is. My git sync-type and squashmount between is already so very custom, that any issues I have with portage won't be supported by anyone on #gentoo.de _________________ppc:PowerBook5,8 15"(1440)-G4/1.67,2G Ram|amd64:HP EliteBook 8560w,i7-2620M,16G Ram|amd64:Acer Z5610 (Core2QuadQ8200),8G Ram|amd64-prefix:OpenSuse
Lila-Theme

I changed for one "squashpoint" the co,pression level to see how it behaves different than lz4. Now i try to remount it, but tit ells me, there is no need. I tried

Code:

squashmount remount -s src

Code:

squashmount umount src
squashmount forget src
squashmount mount src

just creating a file bigger than the threshold let it resquash it. Are there other options available? I thought from the manpage a "-s" on remount would do this ....

EDIT: Maybe it would be nice to check on unmount and/or resquash if some process is sitting in this mountpoint. When a process is using a file in it, resquash/umount will fail. (Hint: lsof)
EDIT: A very very nice and neat tool you wrote there!

squashmount -s remount ... will resquash if there is any change - independent of the THRESHOLD.
However, if there is absolutely no change there is also no need for resquashing. The only exceptional use case I am aware of is the one you mention: When you want to compare various compression methods. However, this use-case is so exceptional that I don't think that it deserves a special option. It is better to call mksquashfs manually when you want to compare these methods.

Quote:

EDIT: Maybe it would be nice to check on unmount and/or resquash if some process is sitting in this mountpoint. When a process is using a file in it, resquash/umount will fail. (Hint: lsof) ;)

lsof is not really reliable. AFAIK there is no reliable method to check this.
Moreover, since the default is to fall back to lazy umounting after an umount failure, resquash will usually succeed anyway (and just print a warning).

I was wondering if putting my /lib(64) on to the RAM would speed up my system, and if is doable via squashmount.

I never tried, but I guess using zram or zcache will give you more improvement. For libs like libc, this is pointless anyway, since they are surely always in use by some running programm and thus mmapped anyway - making another mmap copy costs practically zero for the kernel.

Quote:

What could go wrong and what I have to be careful of?

When you would compress glibc without keeping a copy, you probably cannot start squashmount, because commands like "mount" will need glibc to operate.
Thus, very likely you will have the problem that you cannot pull yourself up by your own bootstraps...
If you have a rescuecd, this is not unrepairable 'though: You just have to "unsquash" the directory again from the rescue cd.

Did you ever place the rootfs on such a "squashpoint" like some embedded systems like routers do it? [1] The point is often the update from that rootfs. You need an other pc for it and mount/create the rootfs.sqfs file there...

Did you ever place the rootfs on such a "squashpoint" like some embedded systems like routers do it?

I had tried years ago with aufs (and squash_dir at that time), and there was no problem. You will have to mount --bind some other directories inside (like /sys /proc etc), and you have to umount them before you can umount the squash filesystem: Since squashmount-10.1.0 this should be easy with the $after_mont and $before_umount hooks.

Maybe it would be nice to check on unmount and/or resquash if some process is sitting in this mountpoint. When a process is using a file in it, resquash/umount will fail. (Hint: lsof)

After sleeping it over: An additional check (even if it is not reliable) cannot hurt.
squashmount-12.0.0 provides now a corresponding --lsof option (and $lsof variable to set the default), and the check defaults to "on", except in the shutdown init scripts where it is explicitly overridden.

Quote:

I thought from the manpage a "-s" on remount would do this ....

Since this is almost a FAQ, meanwhile, squashmount-12.0.0 has a new state THRESHOLD=-2 (and corresponding option --squash-force) which forces a resquash, independent of whether any changes had occured.

I'm not the git expert yet, but after some trials I got that fixed with

Code:

git reset --hard origin/master

, but I need to do that occasionally, it is not an issue with other overlays._________________ppc:PowerBook5,8 15"(1440)-G4/1.67,2G Ram|amd64:HP EliteBook 8560w,i7-2620M,16G Ram|amd64:Acer Z5610 (Core2QuadQ8200),8G Ram|amd64-prefix:OpenSuse
Lila-Theme

I consider this a layman bug: IMHO, layman should not only pull but actually "hard" update. (At the very least, this should be the default, perhaps with a possibility to opt out, although I do not see any reason for such an option.)

Just to make it clear: The layman update problem appears whenever the git repository is rebased (e.g. if something is permanently removed from the history). This does not happen very often, but occassionally it is reasonable, e.g. if an unrelated file was pushed by mistake.

So this was a rebase again? On the mv overlay it happens quite often, I've never seen on other overlays. So I should file this as layman bug? What is the correct command for that hard update?_________________ppc:PowerBook5,8 15"(1440)-G4/1.67,2G Ram|amd64:HP EliteBook 8560w,i7-2620M,16G Ram|amd64:Acer Z5610 (Core2QuadQ8200),8G Ram|amd64-prefix:OpenSuse
Lila-Theme

I think it was 4-7 times in the lifetime of the overlay; usually to permantly remove a commit which was completely broken or very problematic for various reasons.

Quote:

So I should file this as layman bug?

Why not?

Quote:

What is the correct command for that hard update?

I don't know, I never understood these details of git, and I would guess the author of layman does neither - it seems to me that nobody really understands all these details without trying out a lot of cases.
Usually, I remove and re-add an overlay with layman if it happens to me. (And indeed, I always make backups of my git directories since sometimes I am not able to restore a previous state. E.g. after checking out an old version, I get a "deprecated head", and somehow it seems sometimes not possible to restore the previous head - "git list" does not appear to show it with any option, and even if I had taken a note of the hash of the head in advance, I can check it out again, but not make it the new "head" with all rights again. git simply behaves occassionally mysterious to me, and I guess that I am not the only one...)

CHMOD and CHOWN refer to the permissions of the squashfile not of any directories.

In order to change the permissions of DIR after mounting, one could use a post-mount hook.
Alternatively, squashmount-12.2.0 contains also CHMOD_DIR and CHOWN_DIR (with a syntax similar to CHMOD and CHOWN) which are used to change the mode/ownership of DIR after mounting.