# Compressing filesystems with squashfs and squashmount

## mv

Admin edit: Split from TIP: Compressing portage using squashfs: initscript method --pjp

Proudly announcing the successor of squash_dir - written by the maintainer of squash_dir in one weekend...   :Cool: 

squashmount works generically for all init-systems. Its user interface was developed from the beginning to support multiple mount-points.

It does not rely on the init-system to manage the mounts but records the mounts on its own.

Special runtime configuration features of the mounted directories are not managed by "magic files" as in squash_dir but by a clean control interface which is able to save the states until the next reboot.

squashmount is available for gentoo users from the mv overlay or for other users from github.

----------

## yoshi314

what is the status of overlayfs? is that still out of kernel code?

i got a bit fed up with aufs holding me back all the time (and unionfs being a bit unreliable with tmpfs branches), so i stopped using the script for a while.

----------

## mv

 *yoshi314 wrote:*   

> what is the status of overlayfs? is that still out of kernel code?

 

It is unclear to me: Linus has announced once that it should be included, but it seems nothing has happened since then. According to this page it has been mainlined in Linux kernel 3.11 (and contains an officially looking link), but it is not clear to me what this means: The usual announcements in the german Heise forum did not mention it (and these announcements are usually very complete), and also when browsing the kernel git repository, I could not see it.

----------

## yoshi314

there are syntax errors when using example ,e.g. the example has to be:

```
push(@mounts, {

   TAG => 'db',

   DIR => '/var/db',

   FILE => '/var/db.sqfs',

   BACKUP => '/var/db.sqfs.bak', # keep a backup

   CHANGES => '/var/db.changes',

   READONLY => '/var/db.readonly',

```

also, i cannot get it to work with unionfs-fuse package :

 *Quote:*   

> [root@box ~]# squashmount -v start
> 
> [db]:      mounting...
> 
> Failed to open /root/allow_other/: No such file or directory. Aborting!
> ...

 

my config : 

```
@order = ( 'unionfs-fuse' );

push(@mounts, {

   TAG => 'db',

   DIR => '/var/db',

   FILE => '/var/db.sqfs',

   BACKUP => '/var/db.sqfs.bak', # keep a backup

   CHANGES => '/var/db.changes',

   READONLY => '/var/db.readonly',

   THRESHOLD => '30m',

   BLOCKSIZE => 65536

       }, {

               TAG => 'portage',

               DIR => '/usr/portage',

               FILE => '/usr/portage.sqfs',

               CHANGES => '/usr/portage.changes',

               READONLY => '/usr/portage.readonly',

               THRESHOLD => '40m' # resquash on umount if 40 megabytes changed

       });
```

i have unionfs-fuse installed, perhaps i need to enable unionfs then ?

----------

## mv

Thanks for the report.

The example file had already been fixed. Note that the provided helper functions have changed in name and functionality; meanwhile also BACKUP => 1 suffices.

The unionfs-fuse bug has been fixed in squashmount-2.2 (unionfs-fuse had not yet been tested, and there were trivial typos in the call; the same holds for unionfs [which is still untested. Does it still exist yet?]).

----------

## yoshi314

thanks, will test later on today.

edit: works fine now. the initial example looks a bit intimidating, but it's manageable eventually  :Wink: 

----------

## mv

There were some serious issues with <=squashmount-2.4 (first restart was buggy, and the fix had a serious typo concerning umount).

However, the current squashmount-2.5 should be ok.

----------

## yoshi314

how do i disable automatic rebuilds of squashfs images on shutdown? will commenting out the threshold do, or do i have to set it to 0 or really high value?

----------

## mv

 *yoshi314 wrote:*   

> how do i disable automatic rebuilds of squashfs images on shutdown? will commenting out the threshold do, or do i have to set it to 0 or really high value?

 

A negative threshold means "infinity" (even more, it overrides "kill"). If you only mean for the next reboot, you can use something like 

```
squashmount -n set # -n is the short option for --nosquash
```

 which does nothing else than setting temporarily (in /run/squashmount) the threshold to -1.

----------

## yoshi314

after recent update to 2.8 ( i think ) i could not restart existing mounts. 

after manually undoing all union and squashfs mounts, script mounted everything successfully. not sure if that meant i experienced some potential data loss or not.

----------

## mv

 *yoshi314 wrote:*   

> after recent update to 2.8 ( i think ) i could not restart existing mounts.

 

I had this also once, but I was unable to reproduce it. If you know how to reproduce it, please post and the bug can be fixed  :Wink: 

(Maybe it happened from an update of an much earlier version? In this case it could be related due to the change of the format in /var/run).

 *Quote:*   

> after manually undoing all union and squashfs mounts, script mounted everything successfully. not sure if that meant i experienced some potential data loss or not.

 

It does not mean a data loss; squashmount.2.8 contains options -I and -f to help you in such an emergency (when it can). For instance 

```
squashmount -I umount
```

 will try to umount even if it "thinks" that the partition is not mounted; it might be necessary to combine this with -f to try more aggressively.

----------

## yoshi314

seems to be happening again : 

```
[root@box ~]# squashmount status                                    

 * [db]:       not mounted

 * [portage]:  not mounted

 * [overlays]: not mounted

```

```
mount

(....)

/mnt/storage/db.sqfs on /var/db.readonly type squashfs (ro,noatime)

unionfs on /var/db type fuse.unionfs (rw,nosuid,nodev,noatime,user_id=0,group_id=0,default_permissions,allow_other)

/mnt/storage/portage.sqfs on /mnt/storage/portage.readonly type squashfs (ro,noatime)

unionfs on /usr/portage type fuse.unionfs (rw,nosuid,nodev,noatime,user_id=0,group_id=0,default_permissions,allow_other)

/mnt/storage/overlays.sqfs on /mnt/storage/overlays.readonly type squashfs (ro,noatime)

unionfs on /mnt/storage/overlays type fuse.unionfs (rw,nosuid,nodev,noatime,user_id=0,group_id=0,default_permissions,allow_other)

```

my config is as it used to be :

```
@order = ( 'unionfs-fuse' );

push(@mounts, {

   TAG => 'db',

   DIR => '/var/db',

   FILE => '/mnt/storage/db.sqfs',

   BACKUP => '/var/db.sqfs.bak', # keep a backup

   CHANGES => '/var/db.changes',

   READONLY => '/var/db.readonly',

   # Do not resquash everytime but only after 30 megabytes of fresh data:

   THRESHOLD => '30m',

   # Since this directory contains only very small files, we cheat with

   # this size by using that each file takes at least a full block:

   # Hence, the number of files is more important for THRESHOLD than

   # their size. In gentoo, one installed package thus "counts" about

   # 2m in size (although it is actually only 20 very short files):

   BLOCKSIZE => 65536

       }, {

               TAG => 'portage',

               DIR => '/usr/portage',

               FILE => '/mnt/storage/portage.sqfs',

               CHANGES => '/mnt/storage/portage.changes',

               READONLY => '/mnt/storage/portage.readonly',

               THRESHOLD => '20m', # resquash on umount if 40 megabytes changed

          COMPRESSION => 'lzo'

       }, {

               TAG => 'overlays',

               DIR => '/mnt/storage/overlays',

               FILE => '/mnt/storage/overlays.sqfs',

               CHANGES => '/mnt/storage/overlays.changes',

               READONLY => '/mnt/storage/overlays.readonly',

               THRESHOLD => '10m', # resquash on umount if 40 megabytes changed

          COMPRESSION => 'lzo'

       });

      # If /var is on a separate partition, we want that the

      # squashfile is first generated in /var/tmp:

      #TEMPDIR => '/var/tmp',

```

hm, something's odd : 

```
squashmount check -f

 * [db]:       error:   DIR is nonempty!

 * [portage]:  error:   DIR is nonempty!

 * [overlays]: error:   DIR is nonempty!

```

after manual unmounting it reports back fine.

----------

## mv

 *yoshi314 wrote:*   

> seems to be happening again:

 

Can you reproduce what you did to make it happen?

 *Quote:*   

> hm, something's odd : 
> 
> ```
> squashmount check -f
> ```
> ...

 

This is not surprising: squashmount thinks that your original directory is not mounted; since it contains data (namely that from the mount which squashmount is not aware of), it reports the directory as nonempty. The bug happened before: squashmount should not have flagged the directory as umounted (in /run/squashmount) when actually it is mounted.

----------

## yoshi314

 *mv wrote:*   

>  *yoshi314 wrote:*   seems to be happening again: 
> 
> Can you reproduce what you did to make it happen?
> 
> 

 i just booted the system. journalctl logs say it started up fine, i have squashfs and unionfs mounted. only script seems to be having a different opinion on that.

----------

## mv

 *yoshi314 wrote:*   

> i just booted the system. journalctl logs say it started up fine, i have squashfs and unionfs mounted. only script seems to be having a different opinion on that.

 

Ah, systemd. (Normally I run openrc). Then I guess that it is a dependency issue; I will report back.

----------

## mv

The bug is finally fixed: systemd was the correct hint for reproducing (now I remembered that I was testing with systemd when the bug occured in my case).

It was a stupid issue: tmpfiles.d was configured to clean /run/squashmount. So if systemd cleaned this directory after starting squashmount (which could happen by accident since there was no corresponding dependency specified in the systemd service file), it cleaned all information which squashmount had stored about mounted dirs.

The issue is fixed in the current squashmount-2.9, and also the emergency behaviour was improved and explicitly documented.

----------

## Massimo B.

I took a look at the new squashmount. I really appreciate the rewrite in Perl. If things are getting bigger, bash and similars have their restrictions. Even if Perl is not the problem for me, are you going to keep the configuration /etc/squashmount.pl in plain Perl syntax? I think this is quite unusual even for projects written in Perl, at least I know Perl-only users like that, but the configuration is the user interface for non-developers.

So since migrating is not that easy as replacing squash_dir with squashmount, I stay with squash_dir at the moment, trying the switch some time later and watching your squashmount.

I had no issues with different init systems as I just did switch to OpenRC when Gentoo did announce the new default.

----------

## mv

 *Massimo B. wrote:*   

> going to keep the configuration /etc/squashmount.pl in plain Perl syntax?

 

Yes, because it is more appropriate: I also thought first about a "plain" configuration file, but this way you can easily make conditions on something (e.g. I use the same config-file on different machines depending on the existence of some symlinks), you can make certain values (like the compression algorithm) easily the default for all your mount points etc. Moreover, for configuring several mount-points in one file, the syntax of an init-file would not be much simpler anyway.

 *Quote:*   

> So since migrating is not that easy as replacing squash_dir with squashmount

 

If you want, it can be almost that easy: Write

```
push(@mounts, {

TAG => 'portage',

...

}); # do not forget these braces and semicolon!

```

and put into "..." your old configuration, essentially just replacing "=" by "=>", finishing each line except the last with a comma and putting the names into '...' or "..." (as you perhaps already did in squash_dir); repeat this for every mount point (replacing "portage" by a different name of your choice).

Only take care that some variable names have slightly changed (e.g. previous DIRECTORY is now called simpler DIR) and that some global variables have become perl variables; for a "normal" user this involves only the ORDER variable which must now be set differently: 

```
@order = ('overlayfs', 'aufs', 'unionfs-fuse'); # Do not forget the semicolon
```

 Everything else is just syntactic sougar which becomes useful if you have more mount-points (e.g. I have 12 mount-points, and such a huge configuration file becomes much shorter and easier to maintain using perl-syntax shortcuts than if I would repeat the above task 12 times, although the latter would be possible).

 *Quote:*   

> I stay with squash_dir at the moment,

 

I strongly recommend to switch, especially if you ever wanted to omit resquashing for the next boot or force squashing immediately. All this could be done with squash_dir, but is now much simpler and much more convenient.

----------

## Massimo B.

Hi. I was wondering about the sub added_hash{} as it only returns the hash it gets. Ok it merges sub_hashes, maybe meant to ease some default like sub standard_mount{}.

Having some little Perl knowledge I asked in #perl about this approach. Hash::Merge::Simple could be more appropriate.

But anyway, having configuration of executable code and calling functions from there also sounds unusual and PHPish to #perl people. Maybe the gained flexibility is not the most save way and not necessarily desirable. This even made me reading the code and ask Perl coders to understand the configuration example, which should not be the point of a user application. I stay tuned, I liked the squash_dir and I appreciate the new port.

----------

## mv

 *Massimo B. wrote:*   

> Hi. I was wondering about the sub added_hash{} as it only returns the hash it gets. Ok it merges sub_hashes, maybe meant to ease some default like sub standard_mount{}.

 

This is exactly the idea: That you can merge some "defaults" with other data (like standard_mount()). This is also the way it is used in the examples.

 *Quote:*   

> Having some little Perl knowledge I asked in #perl about this approach. Hash::Merge::Simple could be more appropriate.

 

This function is neither in perl-5.18.1 nor in Gentoo at all. Moreover, recursion and other tricks of that function are not needed. added_has() is practically a simplified (non-recursive) variant of Hash::Merge::Simple

 *Quote:*   

> having configuration of executable code and calling functions from there also sounds unusual

 

Nobody forces you to use these features. As I have explained (and hopefully also made clear on the manpage), you can use just a "plain" configuration. If you have perl knowledge you can use perl tricks to avoid the repetition or use other perl code for setup (e.g. source other setup files or whatever). The two functions are there to support you when doing this, but there is no need to do it.

It is a bit comparable with writing LaTeX: If you have to type similar texts several times you either can do this, or you setup some macros which avoid the repetition and allow for easy changing in the repetitions. The two provided functions are just IMHO useful "macros" in this context, but you can completely ignore them and just write the repetitions or write your own functions (e.g. use Hash::Merge::Simple if you have installed it).

----------

## Yamakuzure

 *mv wrote:*   

> 
> 
> ```
> @order = ('overlayfs', 'aufs', 'unionfs-fuse'); # Do not forget the semicolon
> ```
> ...

 Is there a reason to place overlayfs before aufs? Or in other words, are there reasons to prefer overlayfs over aufs? I am currently using aufs and hadto change that particular line, so squashmount won't complain every time that overlayfs isn't available. AFAIK overlayfs is a bit like an AUFS-light, right?

----------

## mv

overlayfs is first, because it appeared when writing squashmount that it would be in the kernel, soon.

Both are more or less equivalent, although there are some known cases where directories from overlayfs do not behave exactly as required by POSIX - aufs contains a lot of code to cover all these (rare) cases correctly.

----------

## Yamakuzure

Thank you very much!

----------

## 188562

By the old wiki Squashed Portage Tree or mirror I make squashed-portage bash script with systemd support. To install layman -a init6; emerge sys-apps/squashed-portage Use the same as old init.d script 

```
/usr/sbin/squashed-portage start

/usr/sbin/squashed-portage stop

/usr/sbin/squashed-portage reload
```

or:

```
systemctl start portage.service

systemctl stop portage.service

systemctl reload portage.service
```

----------

## mv

 *init_6 wrote:*   

> bash script with systemd support.

 

This is fine, but already squash_dir with systemd support could do much more (squashing only if threshold is reached, ignoring unimportant files, support for multiple mount points, fallbacks to alternatives to aufs, rather secure error handling, etc). The new implementation squashmount has even a lot more features, especially concerning the user interface (conveniently forcing/omitting resquashing immediately/later on, killing previous modification currently/next time/forever, ...) and is (after the birth problems have been fixed) probably also the safest choice concerning various error handing. The price for the features is a somewhat more complex setup of the mount-points, but I hope that after the setup the actual user interface is rather intuitive.

BTW, here is another argument, why it is useful to have a setup file in perl: You can use it to set the order of the tools depending on a test what your current kernel does support. Examples will probably be given in the next release of squashmount. Here just an untested one:  */etc/squasmount.pl wrote:*   

> if(system('modprobe aufs >/dev/null 2>&1')) {
> 
>   @order = ('aufs', 'unionfs-fuse')
> 
> } elsif(system('modprobe overlayfs >/dev/null 2>&1'))
> ...

 

----------

## slycordinator

On my end squashmount always attempts to create a squashfs file for the "games" directory at /usr/share/games with the LZO compression scheme. And this always fails because I followed the general advice of the kernel config to not include LZO support.

----------

## mv

 *slycordinator wrote:*   

> On my end squashmount always attempts to create a squashfs file for the "games" directory

 

You must modify the provided /etc/squashmount.pl to your needs - this is just full of various examples (among them an example for the games directory with COMPRESSION => 'lzo').

If you have already squashed directories which you did not intend to you can use the unsquash program (after(!) umounting the directories with squashmount) to get the original data back.

----------

## slycordinator

Any particular reason you chose lzo for that? Were you finding it performed better for the games directory or something?

NM I read why in that file

----------

## emc

I will try it

----------

## slycordinator

With squashmount-3.6 installed I get:

```
 * umounting/stopping squashmount ...

error parsing /etc/squashmount.pl: Undefined subroutine &CFG::getpwname called at /etc/squashmount.pl line 40.

stopped at /usr/bin/squashmount line 2082.                                                                                                                                   [ !! ]

 * ERROR: squashmount failed to stop
```

----------

## mv

 *slycordinator wrote:*   

> error parsing /etc/squashmount.pl: Undefined subroutine &CFG::getpwname called at /etc/squashmount.pl line 40

 

Typo in config: should be getpwnam (not getpwname).

----------

## _______0

i'd like to try this.

where's the updated version that works with copy paste?

The script has a lot of variables and symbols and lines.

I wonder what's the difference between the script method and manually mounting a temp folder in ram then 7z'ed?

simple steps:

1- create a dir in ram:

```
mkdir /tmp/portage
```

2- mount ram:

```
mount -t tmpfs,size=1G /tmp/portage
```

3- rsync your portage dir unto it.

```
rsync -Pvhr --exclude=distfiles /usr/portage/ /tmp/portage
```

4- edit make.conf:

```
PORTDIR=/tmp/portage
```

5- emerge sync, and/or work with portage as normal:

emerge --sync

6- compress it with pigz back to the hard drive, with multiple thread options should be awsome!!:

```
time tar cf - portdir/ | pigz -c -9 > portage.tar.gz

real    0m3.708s

user    0m26.297s

sys     0m1.406s

```

```
ls -sh portage.tar.gz 

81M portage.tar.gz

```

7- when rebooting de-compress after step 2 above.

```
to do
```

This method no need to unmount as rebooting destroys /tmp/portage.

emerge -pv system

in ram (type tmpfs):

```
real    0m16.902s

user    0m16.556s

sys     0m0.251s

```

in hard drive with xfs:

```
real    0m36.389s

user    0m20.462s

sys     0m0.462s

```

Haven't done a full cache flash but did the test over and over to check is not one time numbers. They are consistent.

And my ram isn't the fastest out there.

ps: got confused with best compression/decompression method. 7z uses ONE core!!!?? tried this (ultra settings found in man page):

```
7z a -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on portage.7z portdir
```

had to ctrl-c, because using one core and taking too long.

Didn't find a way to completely unpigz since I was left with portage.tar :/

----------

## mv

 *_______0 wrote:*   

> i'd like to try this.
> 
> where's the updated version that works with copy paste?

 

If you mean synss' original script, this is not maintained since ages. The actively maintained version is squashmount from the mv overlay, but except for some variable names and the basic idea this has nothing in common anymore with the original script.

 *Quote:*   

> I wonder what's the difference between the script method and manually mounting a temp folder in ram then 7z'ed?

 

Here are the main differences:

 You loose a lot of ram for no gain. For directories like texmf-dist for which you do it more for size than speed, this is completely indiscussible. Only for the portage tree it might be acceptable if you have lot of ram to waste, but why waste it unnecessarily?

 You must recompress after every change - no possibilities to compress only when a threshold is reached.

 On unclean shutdown (e.g. crash) all changes are lost.

 You must unpack after every reboot.

 You do not have a readonly version of the portage tree to compare changes with easily.

 You do not have a directory in which you can see quickly which files actually have changed. (This is rather convenient e.g. after syncing the portage tree, although you can of course also use "find" and friends with timestamps).

 After all these disadvantages, what is the advantage? Maybe a slightly better compression (hower, I didn't realize a significant increase in compression size for the squashfs format; lzma should be about as small as 7z, although it is certainly possible to construct some theoretical examples in which one of the two wins clearly). Another advantage is clearly that no kernel patches are needed. This advantage will only vanish when linux upstream finally includes aufs/overlayfs/something else. That things work since many years but are not included upstream is really a sad story for years which makes me more and more doubt aobut the idea of free software. (Of course, e2compr is another such sad story...)

----------

## _______0

7z is:

```
time 7z a -t7z -mmt=on -m0=lzma2 -mx=9 -mfb=64 -md=32m -ms=on portage.7z portdir/

real    1m57.155s

user    5m51.693s

sys     0m7.447s

54M portage.7z
```

But it takes way longer than pigz. Cores are not at full and at the end of the compression process there's only one working at 100%. And p7zip -d[/d] doesn't decompress using multiple core.

With [b]pigz

```
81M portage.tar.gz
```

But again, decompressing leaves a 400MB portage.tar :/

Is there a way to compress portage dir with pigz without tar? I want to check fully threaded de-compression.

Ok so your script looks nice, where to get it? Link?

I didn't get your last part:

```
This advantage will only vanish when linux upstream finally includes aufs/overlayfs/something else. That things work since many years but are not included upstream is really a sad story for years which makes me more and more doubt aobut the idea of free software. (Of course, e2compr is another such sad story...)
```

What will be included and what will vanish? squashfs will vanish?

e2compr is an interesting development.

----------

## mv

 *_______0 wrote:*   

> What will be included and what will vanish? squashfs will vanish?

 

I hope that some day aufs or overlayfs or something similar will be included. Then the disadvantage that you need a patched kernel will vanish.

 *Quote:*   

> e2compr is an interesting development.

 

Yes, it was excellent and maintained over many kernel versions. The problem is that upstream rejected it like aufs for no serious reasons (a few technical arguments were invented like theoretical problems with unmodified e2fsck in some corner cases, but it is obvious that the real reason is only NIH syndrome). Eventually the developer of e2compr gave up.

This is the main problem with open source, that upstream practically has full power and is not forced to decide on technical reason. In theory everybody can fork the kernel (or gnome, kde, systemd etc.) but in practice nobody has the resources to do that so that we all have to take what is shoved down our throats. It is not much different to proprietary software.

----------

## emc

Problem with overlay?

```
gopher emc # eix -I squashmount

-- Invalid line 1 in /var/lib/layman/mv/profiles/package.mask: '<<<<<<< ...'

    Can't read category.

-- Invalid line 3 in /var/lib/layman/mv/profiles/package.mask: '======= ...'

    Can't read category.

-- Invalid line 5 in /var/lib/layman/mv/profiles/package.mask: '>>>>>>> ...'

    Can't read category.

-- Invalid line 1 in /var/lib/layman/mv/profiles/package.mask: '<<<<<<< ...'

    Can't read category.

-- Invalid line 3 in /var/lib/layman/mv/profiles/package.mask: '======= ...'

    Can't read category.

-- Invalid line 5 in /var/lib/layman/mv/profiles/package.mask: '>>>>>>> ...'

    Can't read category.

[I] sys-fs/squashmount [1]

     Available versions:  (~)3.7-r1^m (~)3.8^m

     Installed versions:  3.8^m(01:06:44 AM 11/23/2013)

     Homepage:            http://forums.gentoo.org/viewtopic-t-465367.html

     Description:         Keep directories compressed with squashfs. Useful for portage tree, texmf-dist

[1] "mv" /var/lib/layman/mv
```

----------

## mv

 *emc wrote:*   

> Problem with overlay?

 

The overlay (and also many git packages) were rebased to update the email backward in history. layman cannot deal with rebased repositories. "Solution": 

```
layman --delete mv; layman --add mv
```

For packages it might be necessary to remove the git source from your DISTDIR manually before reemerging.

----------

## emc

mv:

I have to say I'm a bit lost, what I really need to start squashmount with?

Currentlly I'm using geek-sources with aufs USE flag (beside other patches)

```
# grep AUFS .config213_4

CONFIG_AUFS_FS=y

CONFIG_AUFS_BRANCH_MAX_127=y

# CONFIG_AUFS_BRANCH_MAX_511 is not set

# CONFIG_AUFS_BRANCH_MAX_1023 is not set

# CONFIG_AUFS_BRANCH_MAX_32767 is not set

CONFIG_AUFS_SBILIST=y

# CONFIG_AUFS_HNOTIFY is not set

# CONFIG_AUFS_RDU is not set

# CONFIG_AUFS_SP_IATTR is not set

# CONFIG_AUFS_SHWH is not set

# CONFIG_AUFS_BR_RAMFS is not set

# CONFIG_AUFS_BR_FUSE is not set

# CONFIG_AUFS_DEBUG is not set
```

I have as well:

```
# eix -I aufs

[I] sys-fs/aufs-headers

     Available versions:  (~)3.11_p20130915

     Installed versions:  3.11_p20130915(10:10:36 AM 10/06/2013)

     Homepage:            http://aufs.sourceforge.net/

     Description:         User space headers for aufs3

[I] sys-fs/aufs-util

     Available versions:  (~)3.9_p20130915 **99999999(0/3.9)*l[1]

     Installed versions:  3.9_p20130915(10:12:39 AM 10/06/2013)

     Homepage:            http://aufs.sourceforge.net/

     Description:         Userspace tools for aufs

[U] sys-fs/aufs3

     Available versions:  (~)3_p20131007 (~)3_p20131014 (~)3_p20131104-r1 (~)3_p20131111-r1 {debug doc fuse hfs inotify kernel-patch nfs pax_kernel ramfs KERNEL="linux"}

     Installed versions:  3_p20130928(09:54:13 PM 10/07/2013)(-debug -doc -fuse -hfs -inotify -kernel-patch -nfs -pax_kernel -ramfs KERNEL="linux")

     Homepage:            http://aufs.sourceforge.net/

     Description:         An entirely re-designed and re-implemented Unionfs

[1] "mv" /var/lib/layman/mv
```

and upgrade aufs3 failed because CONFIG_AUFS_FS=y was set, but I i was succesfully instal in first place.

Anyway the question is what I need to start using squashmount. Kernel with aufs support but why aufs3 package failed, should I set CONFIG_AUFS_FS=m?

----------

## mv

If you do have a kernel with aufs patches (like probably geek sources), you need nothing else: You must enable squashfs and aufs in the kernel ("m" is probably more tested, but "y" should work as well) and setup the appropriate /etc/squashmount.pl

----------

## emc

Can you do anything regarding last crash of overlays.gentoo.org:

```
# layman -a mv

 * Adding overlay,...

 * Running Git... # ( cd /var/lib/layman  && /usr/bin/git clone git://git.overlays.gentoo.org/user/mv.git /var/lib/layman/mv )

Cloning into '/var/lib/layman/mv'...

fatal: read error: Connection reset by peer

 * Failure result returned from Git

 * Running Git... # ( cd /var/lib/layman/mv  && /usr/bin/git config user.name "layman" )

 * [Errno 2] No such file or directory: '/var/lib/layman/mv'

 * 

 * Trying next source of listed sources...

 * Running Git... # ( cd /var/lib/layman  && /usr/bin/git clone http://git.overlays.gentoo.org/gitroot/user/mv.git/ /var/lib/layman/mv )

Cloning into '/var/lib/layman/mv'...

error: File 8c89b13b1966abb6f1695254fe497968b03fe6a4 (http://git.overlays.gentoo.org/gitroot/user/mv.git/objects/8c/89b13b1966abb6f1695254fe497968b03fe6a4) corrupt

error: Unable to find 8c89b13b1966abb6f1695254fe497968b03fe6a4 under http://git.overlays.gentoo.org/gitroot/user/mv.git

Cannot obtain needed object 8c89b13b1966abb6f1695254fe497968b03fe6a4

error: Fetch failed.

 * Failure result returned from Git

 * Running Git... # ( cd /var/lib/layman/mv  && /usr/bin/git config user.name "layman" )

 * [Errno 2] No such file or directory: '/var/lib/layman/mv'

 * 

 * Trying next source of listed sources...

 * Running Git... # ( cd /var/lib/layman  && /usr/bin/git clone git+ssh://git@git.overlays.gentoo.org/user/mv.git /var/lib/layman/mv )

Cloning into '/var/lib/layman/mv'...

Permission denied (publickey).

fatal: Could not read from remote repository.

Please make sure you have the correct access rights

and the repository exists.

 * Failure result returned from Git

 * Running Git... # ( cd /var/lib/layman/mv  && /usr/bin/git config user.name "layman" )

 * [Errno 2] No such file or directory: '/var/lib/layman/mv'

 * Adding repository "mv" failed!

 * CLI: Errors occurred processing action add

 * Adding repository "mv" failed!
```

----------

## mv

 *emc wrote:*   

> Can you do anything regarding last crash of overlays.gentoo.org

 

Edit: Somebody is working on this

----------

## qsuscs

I have this configuration for squashmount (okay, it's actually the "default"):

```
        standard_mount('portage', '/usr/portage', $defaults, {

                THRESHOLD => '80m',

                # Any change in the local/ subdirectory (except in .git,

                # profiles, metadata) should lead to a resquash, even if

                # the threshold is not reached:

                FILL => qr{^local/(?!(\.git|profiles|metadata)(/|$))}

        })
```

So I have the directories /usr/{portage|portage.readonly|portage.changes}. According to mount(8), /usr/portage.sqfs is mounted on /usr/portage.readonly, and "aufs" is mounted on /usr/portage. [s]I’d guess that the overlay consists of /usr/portage.readonly and /usr/portage.changes (is there a way to find out? mount(8) isn’t particularly helpful: aufs on /usr/portage type aufs (rw,noatime,si=d3ae66ea856a49d)).[/s] EDIT: Yep, /sys/fs/aufs/si_d3ae66ea856a49d contains all that info. (and why does cross-out not work)

If there is no according entry in mount(8), does that mean that /usr/portage.changes is actually written on disk?

Is /usr/portage.readonly respectively /usr/portage then read from /usr/portage.sqfs directly or from RAM? Can I also put that and /usr/portage.changes into the RAM? I mean, if any changes get lost, another emerge --sync will do, and since I’ve usually ~10G of RAM free, I’ll most likely not even notice that 700M from the portage tree.

----------

## mv

 *qsuscs wrote:*   

> I’d guess that the overlay consists of /usr/portage.readonly and /usr/portage.changes

 

Yes; this is how the standard_mount function works

 *Quote:*   

> is there a way to find out? mount(8) isn’t particularly helpful

 

For overlayfs, mount prints also the parameters upperdir and lowerdir, but for aufs this may be different, of course. It might also depens on your aufs/kernel/mount version. To find out what squashmount thinks about it, you can use

```
squashmount print-changes
```

 *Quote:*   

> If there is no according entry in mount(8), does that mean that /usr/portage.changes is actually written on disk?

 

Yes, this intentional: If you reboot without resquashing you should not have lost the changes. Moreover, you need not resquash at every reboot after only a few changes if you set THRESHOLD.

 *Quote:*   

> Can I also put that and /usr/portage.changes into the RAM

 

Of course. An example is on the "manpage" (I just realize that there is a typo: => is meant here):

```
CHANGES => sub { return File::Temp::newdir(undef, DIR => '/path/to/ramdisk') }
```

Alternatively, if you have /tmp as a ramdisk, just do not specify CHANGES: Then CHANGES becomes a temporary directory in /tmp. (However, note that if you use the standard_mount function to define your mountpoint then CHANGES is automatically set; therefore you must use something like

```
CHANGES => undef
```

to unset it explicitly in this case.) However, I would consider it a bad idea to waste valuable RAM permanently just to store changes in the portage tree: If e.g. an eclass is changed, a lot of files are stored here, and you will not regain this RAM. In the best case, it is then swapped to disk...

 *Quote:*   

> Is /usr/portage.readonly respectively /usr/portage then read from /usr/portage.sqfs directly or from RAM?

 

/usr/portage.readonly is read from /usr/portage.sqfs, but the kernel/squashfs has some mechanisms to cache the data. In the forthcoming kernel 3.13 there are even some improvements of these mechanisms. /usr/portage is just the "merge" of /usr/portage.readonly and /usr/portage.changes, so it must read from both directories. Of course, also in this case some caching mechanisms hold.

----------

## qsuscs

Thanks for that answer, now everything works fine.

I eventually figured out that I’d have to unset CHANGES, but I don’t know perl at all, unfortunately.

I did see the documentation to overlayfs, but I couldn’t figure out how to use it, so I just used aufs.

And as I said, I don’t use too much of my RAM, most of it is free. I build everything there, even libreoffice, and even without swap, I never ran into memory problems. After today’s sync, the portage changes dir is only 3.2M of size, but I doubt that I’d notice 500M.

----------

## Massimo B.

On a new i5 CPU I like to benchmark the different COMPRESSION. How can I force re-squash with a different cipher set with old squash_dir-13.4-r1? I already tried -s but it does not re-squash:

```
$ squash_dir -s restart portage

/etc/init.d/squash_portage stop    # is unmodified
```

----------

## mv

 *Massimo B. wrote:*   

> On a new i5 CPU I like to benchmark the different COMPRESSION. How can I force re-squash with a different cipher set with old squash_dir-13.4-r1?

 

Force resquashing: 

```
squash_dir -fs restart
```

 However, with squash_dir you are not able to change COMPRESSION on the fly: You must edit the configuration. This is the fault of squash_dir relying in openrc: It is not possible to pass environment variables through openrc (unless you mess around with openrc configuration itself). With squashmount you can do it on the fly: 

```
squashmount -fsx xz remount
```

----------

## gringo

hi all,

when i booted today i realized /var/db wasnt mounted and restarted the service to see why :

```
may 20 20:22:43 mountain systemd[1]: Stopping mount/umount all squashmount configured mountpoints...

may 20 20:22:43 mountain squashmount[1406]: * [db]:      error:   not mounted

may 20 20:22:43 mountain squashmount[1406]: * [db]:      forgetting settings

may 20 20:22:45 mountain squashmount[1406]: * [portage]: umounting...

may 20 20:22:45 mountain squashmount[1406]: * [portage]: forgetting settings

may 20 20:22:45 mountain systemd[1]: Starting mount/umount all squashmount configured mountpoints...

may 20 20:22:45 mountain squashmount[1414]: * [db]:      mounting...

may 20 20:22:45 mountain squashmount[1414]: mount: wrong fs type, bad option, bad superblock on /dev/loop0,

may 20 20:22:45 mountain squashmount[1414]: missing codepage or helper program, or other error

may 20 20:22:45 mountain squashmount[1414]: In some cases useful info is found in syslog - try

may 20 20:22:45 mountain squashmount[1414]: dmesg | tail or so.

may 20 20:22:45 mountain kernel: SQUASHFS error: Filesystem uses "unknown" compression. This is not supported

may 20 20:22:45 mountain squashmount[1414]: * [db]:      error:   failed to mount squashfile

may 20 20:22:45 mountain squashmount[1414]: * [portage]: mounting...

may 20 20:22:45 mountain systemd[1]: Started mount/umount all squashmount configured mountpoints.
```

havent touched this since setup :

```
#!/usr/bin/perl

@order = ( 'unionfs-fuse' );

push(@mounts, {

   TAG => 'db',

   DIR => '/var/db',

   FILE => '/var/db.sqfs',

   BACKUP => '/var/db.sqfs.bak',

   CHANGES => '/var/db.changes',

   READONLY => '/var/db.readonly',

   THRESHOLD => '30m',

   BLOCKSIZE => 65536

   }, {

   TAG => 'portage',

   DIR => '/var/repos/portage',

   FILE => '/var/repos/portage.sqfs',

   CHANGES => '/var/repos/portage.changes',

   READONLY => '/var/repos/portage.readonly',

   THRESHOLD => '40m'

   });

```

this is with 6.0, i think im missing sth. obvious here and dont want to mess around before i hear someone elses thoughts.

cheers guys

----------

## mv

The default COMPRESSION value has changed from 'xz' to 'lz4'.

Unfortunately, it seems that lz4 support for squashfs is not yet in the mainstream kernel (although lz4 support is in the kernel since quite a while, a brief harmless patch was submitted a year ago, and mksquashfs supports lz4).

Not sure what to do now: Does anybody know whether squashfs with lz4 can be expected in a reasonable time in the kernel?

(If not, maybe it is necessary to release a squashmount version with different defaults).

To avoid the problem, set the COMPRESSION value explicitly.

Now that you have already compressed in lz4 format, you must resquash: Use 

```
unsquash /path/to/your/squashfile # to unpack

mksquash /path/of/unpackad/data /path/to/squashfile -noappend -comp xz

rm -rf  /path/of/unpackad/data
```

(if you have customized the MKSQUASH variable append its value also to the second command.)

----------

## mv

In the new squashmount-6.0a, it is reverted to the COMPRESSION=xz default.

When mainstream kernel supports squashfs with lz4, this release will probably be considered obsolete, but perhaps this will never happen.

@gringo: This means when you update you can keep your original configuration. However, the archives which are now in lz4 format have to be transferred back to xz format in the way described in the previous posting.

----------

## gringo

thanks @mv : everything worked as you described.

cheers guys

----------

## costel78

When I try to stop squashmount service I get:

```
iul 27 23:32:16 gentoo squashmount[999]: * [portage]: umounting...

iul 27 23:32:16 gentoo squashmount[999]: /sbin/umount.aufs:br.c:47: internal error, /usr/portage: Inappropriate ioctl for device

iul 27 23:32:16 gentoo squashmount[999]: * [portage]: error:   non-lazy umount failed,

iul 27 23:32:16 gentoo squashmount[999]: using lazy umount of /usr/portage

iul 27 23:32:16 gentoo squashmount[999]: /sbin/umount.aufs:br.c:47: internal error, /usr/portage: Inappropriate ioctl for device

iul 27 23:32:16 gentoo squashmount[999]: * [portage]: error:   lazy umount failed: /usr/portage

iul 27 23:32:16 gentoo squashmount[999]: * [db]:      umounting...

iul 27 23:32:16 gentoo squashmount[999]: /sbin/umount.aufs:br.c:47: internal error, /var/db: Inappropriate ioctl for device

iul 27 23:32:16 gentoo squashmount[999]: * [db]:      error:   non-lazy umount failed,

iul 27 23:32:16 gentoo squashmount[999]: using lazy umount of /var/db

iul 27 23:32:16 gentoo squashmount[999]: /sbin/umount.aufs:br.c:47: internal error, /var/db: Inappropriate ioctl for device

iul 27 23:32:16 gentoo squashmount[999]: * [db]:      error:   lazy umount failed: /var/db
```

Packages version and use flags:

```
[ebuild   R    ] sys-fs/aufs-headers-3.15_p20140728  0 kB

[ebuild   R    ] sys-fs/aufs-util-3.15_p20140728  0 kB

[ebuild   R    ] sys-kernel/aufs-sources-3.15.6:3.15.6  USE="experimental symlink -build -deblob -module -vanilla" 0 kB

[ebuild   R    ] sys-fs/squashmount-7.7::added  0 kB

[ebuild   R    ] sys-fs/squashfs-tools-4.3::added  USE="xz -lz4 -lzma -lzo -xattr" 0 kB
```

Config file:

```
#!/usr/bin/perl (this is only for editors)

# The tools which we have installed; if possible only the first in this list

# is used, but the others are a fallback if that fails.

@order = ('aufs', 'overlayfs', 'unionfs-fuse', 'unionfs', 'funionfs');

# Even if we define following is empty it is convenient to use

# this local variable throughout, so that we can simply change it:

my $defaults = {

   COMPRESSION => 'xz'

};

push(@mounts, {

   TAG => 'portage',

   DIR => '/usr/portage',

   FILE => '/usr/portage.sqfs',

   CHANGES => '/usr/portage.changes',

   READONLY => '/usr/portage.readonly',

   THRESHOLD => '50m' # resquash on umount if 40 megabytes changed

}, {

   TAG => 'db',

   DIR => '/var/db',

   FILE => '/var/db.sqfs',

   CHANGES => '/var/db.changes',

   READONLY => '/var/db.readonly',

   THRESHOLD => '30m' # resquash on umount if 40 megabytes changed

}

);
```

Obviously I use systemd and I didn't notice the error but during shutdown/reboot system take unusually long and culprit seems to be squashmount. It recompress despite the *.changes are well bellow threshold.

I tried to start from scratch with same results: with squashmount started compress portage and db directories, disable squashmount service, reboot, put data back and start squashmount. It does not recompress the whole thing unless threshold is reached but systemctl stop squashmount fail with above errors. Kernel config didn't change recently. 

Any help is really appreciated. Thank you!

----------

## mv

[quote="costel78"]When I try to stop squashmount service I get:

```
iul 27 23:32:16 gentoo squashmount[999]: * [portage]: umounting...

iul 27 23:32:16 gentoo squashmount[999]: /sbin/umount.aufs:br.c:47: internal error, /usr/portage: Inappropriate ioctl for device

iul 27 23:32:16 gentoo squashmount[999]: * [portage]: error:   non-lazy umount failed,

iul 27 23:32:16 gentoo squashmount[999]: using lazy umount of /usr/portage

iul 27 23:32:16 gentoo squashmount[999]: /sbin/umount.aufs:br.c:47: internal error, /usr/portage: Inappropriate ioctl for device

iul 27 23:32:16 gentoo squashmount[999]: * [portage]: error:   lazy umount failed: /usr/portage

iul 27 23:32:16 gentoo squashmount[999]: * [db]:      umounting...

iul 27 23:32:16 gentoo squashmount[999]: /sbin/umount.aufs:br.c:47: internal error, /var/db: Inappropriate ioctl for device

iul 27 23:32:16 gentoo squashmount[999]: * [db]:      error:   non-lazy umount failed,

iul 27 23:32:16 gentoo squashmount[999]: using lazy umount of /var/db

iul 27 23:32:16 gentoo squashmount[999]: /sbin/umount.aufs:br.c:47: internal error, /var/db: Inappropriate ioctl for device

iul 27 23:32:16 gentoo squashmount[999]: * [db]:      error:   lazy umount failed: /var/db
```

/quote]

This is an aufs problem in your installation; perhaps recompiling aufs-util helps.

I had some problems without /sbin/umount.aufs, too, and have decided to remove it (Some hardlink information on the filesystems might get lost, but this is not needed for the portage tree). Perhaps, a variable should be added to squashmount by which one can add umount options like -I for each mountpoint separately.

Note that squashmount has no sane way to recover from this error: Removing the data in CHANGES might even crash the system after such a bug, and keeping it, leads to inconsistent states.

 *Quote:*   

> It recompress despite the *.changes are well bellow threshold.

 

Did you take into account that if you set a huge BLOCKSIZE the threshold is reached much earlier if you have many small files (as in the portage directory?)

Does the recompression happen even if 

```
squashmount list
```

 shows that it should not happen? (This would be rather strange)

----------

## costel78

Recompiling sys-fs/aufs-util-3.15_p20140728 did not help.

Recompressing on every stop did not occurred since starting from scratch.

gentoo costel # squashmount list

 * [portage]: aufs  (50m), modified, but will not resquash

 * [db]:      aufs  (30m), modified, but will not resquash

To be on the safe side I'll stop using squashmount for a while (yes, it's clear now for me that IT IS NOT his fault) on portage and db. I'll keep a small directory on squashmount to monitor when problem will disappear. 

Thank for support!

----------

## mv

 *costel78 wrote:*   

> Recompiling sys-fs/aufs-util-3.15_p20140728 did not help.

 

I cannot help here.

In squashmount-7.8 there is support added for umount options (one of the few things squashmount was missing compared to squash_dir).

In your situation, it might help to add to your  */etc/squashmount.pl wrote:*   

> @umount = ('-i');

  (with squashmount-7.8).

This is somewhat a hack, but AFAIK the worst thing which can happen by this is that some hardlink information gets lost, i.e. files are stored in duplicate instead of once. Except for very special directories this is not an issue, and for the /usr/portage and /var/db directories, hardlinks are not used, anyway.

----------

## costel78

I had this evening more time to investigate. The error appear with  >=sys-fs/aufs-util-3.15_p20140721. I reported bug 518418.

Unfortunately, umount options didn't change the behaviour. It still failed to umount, but I masked 

```
>=sys-fs/aufs-headers-3.15_p20140721

>=sys-fs/aufs-util-3.15_p20140721
```

 and squashmount it running flawless again   :Very Happy: 

I put a squashmount restart on my update script, so will be more easy to discover if something goes wrong from now on.

Thank you for working on squashmount! Nice piece of software.

----------

## lost+found

I can recommend using unionfs-fuse with gzip, if file size doesn't matter. It has proven to be fast and reliable to me. I'm using squashmount mainly to speed up emerge/portage/kernel source operations on JFS filesystems. I think it prevents file system fragmentation too. A very useful tool indeed!

----------

## mv

 *costel78 wrote:*   

> It still failed to umount

 

But I hope, not because of complaining about a problem with /sbin/umount.aufs; it would be a bug in either squashmount or umount (or a typo in your configuration...) if this tool would have been called.

----------

## mv

 *lost+found wrote:*   

> I can recommend using unionfs-fuse with gzip, if file size doesn't matter

 

If file size does not matter, you should use lz4: You get an enormous speed increase, see the file compression.txt in current versions of squashmount.

However, be aware that this cannot be used with <linux-3.16; I hope that it will be included in linux-3.16, finally.

When a kernel supporting it is out for quite while, it might become default method for squashmount. (Take this a warning for those who need to use older kernels: For new releases, be aware to read the ChangeLog if you need to set something)

----------

## costel78

 *mv wrote:*   

>  *costel78 wrote:*   It still failed to umount 
> 
> But I hope, not because of complaining about a problem with /sbin/umount.aufs; it would be a bug in either squashmount or umount (or a typo in your configuration...) if this tool would have been called.

 

Yes, exactly same error. Maybe config file is wrong ?

```
#!/usr/bin/perl (this is only for editors)

# The tools which we have installed; if possible only the first in this list

# is used, but the others are a fallback if that fails.

@order = ('aufs', 'overlayfs', 'unionfs-fuse', 'unionfs', 'funionfs');

# Even if we define following is empty it is convenient to use

# this local variable throughout, so that we can simply change it:

my $defaults = {

   COMPRESSION => 'xz'

};

push(@mounts, {

   TAG => 'portage',

   DIR => '/usr/portage',

   FILE => '/usr/portage.sqfs',

   CHANGES => '/usr/portage.changes',

   READONLY => '/usr/portage.readonly',

   THRESHOLD => '50m' # resquash on umount if 40 megabytes changed

}, {

   TAG => 'db',

   DIR => '/var/db',

   FILE => '/var/db.sqfs',

   CHANGES => '/var/db.changes',

   READONLY => '/var/db.readonly',

   THRESHOLD => '50m' # resquash on umount if 40 megabytes changed

}

);

@umount = ('-i');
```

Anyway, manually using squashfs and aufs result in the same result with laters aufs-utils.

----------

## mv

There's a bug in this new feature of squashmount  :oops: 

@umount and @umount_ro are used oppositely as intended/documented in 7.8 and 7.9. This is fixed in 7.10.

Thus (temporarily for testing until you install 7.10) you should replace @umount by @umount_ro.

 *Quote:*   

> Anyway, manually using squashfs and aufs result in the same result with laters aufs-utils

 

Did you use option -i with umount when doing things manually?

----------

## costel78

```
[ebuild   R    ] sys-fs/aufs-headers-3.15_p20140728  0 kB

[ebuild   R    ] sys-fs/aufs-util-3.15_p20140728  0 kB

[ebuild   R    ] sys-fs/squashmount-7.10::added  0 kB
```

Everything is working just fine.   :Smile: 

Manually, error occurred without -i. With it set, it worked.

Thank you very much!

----------

## Massimo B.

It feels like since the latest update

```
Wed Aug 13 12:04:32 2014 >>> sys-fs/aufs3-3_p20140811
```

the mounting takes very long. It does not fail but takes around 20 seconds. That makes booting up take very long for around 10 squash directories, while there are no errors in logfiles. Is there any verbose mode?

```
$ squash_dir start portage

Starting portage...

 * Mounting /usr/portage.sqfs as /usr/portage ...                                                   [ ok ]
```

```
$ mount |grep "/usr/portage"

/usr/portage.sqfs on /usr/portage.readonly type squashfs (ro,noatime)

aufs on /usr/portage type aufs (rw,noatime,si=782a68c3173c92b0)
```

Yes, I'm still using squash_dir.

While there was no failure now for a long time but I remember hassle when forced to use a boot-cd to re-emerge some things, is there some emergency start of squash_dir or your new squashmount, that usually is able to mount all directories on well stuffed live-cd environment from inside Gentoo-CHROOT?

----------

## mv

 *Massimo B. wrote:*   

> It feels like since the latest update
> 
> ```
> Wed Aug 13 12:04:32 2014 >>> sys-fs/aufs3-3_p20140811
> ```
> ...

 

Since aufs3 was lagging behind for a while and perhaps only overlayfs will go into upstream kernel, I have currently only kernels with overlayfs for testing.

(However, squash_dir currently does not support latest changes in overlayfs, and unless someone sends patches, I will not update it anymore - squash_dir is now really abandoned...)

How does it work if you send the commands manually?

Something like 

```
modprobe squashfs

mount -t squashfs -o loop,ro,noatime -- /path/to/SQUASHFILE /path/to/READONLY

modprobe aufs3

mount -t aufs [your options from MOUNT_AUFS] -o noatime -o br:/path/to/CHANGES=rw:/path/to/READONLY=rr -- aufs /path/to/DIRECTORY
```

Probably, you want to use -v as an additional option to the last mount command.

If the latter command really just takes 20 seconds and writes nothing out (into systemlog or stdout/stderr), I am afraid that I cannot help: You have to ask the aufs author.

 *Quote:*   

> Is there any verbose mode?

 

Not in squash_dir. In squashmount, there is: If you specify -v sufficiently often, you will see the above commands. But this won't help either, if these commands do not produce any usable output...

 *Quote:*   

> is there some emergency start of squash_dir or your new squashmount, that usually is able to mount all directories on well stuffed live-cd environment from inside Gentoo-CHROOT?

 

No. If you hav a suggestion for a corresponding configuration file for squashmount (or perhaps need some functionality added for this), please send it per PM or report a bug on the squashmount bugtracker on github (or directly send a pull request if you have patches ready   :Wink:  )

----------

## mv

Due to the recent discussion, squashmount has now obtained some enhanced configuration possibilities (e.g. suitable for non-permanent mount-points like for CDs).   :Wink: 

----------

## Massimo B.

Ok, I started migration to squashmount:

It seems /etc/squashmount.pl is the one and only configuration. Please make the config file configurable or distribute the example squashmount.pl additionally in /usr/share/doc/squashmount*.

Because lot of the example is enabled which I don't need, it is harder to keep the example and merging new changes. You could also place some /etc/squashmount.pl.example beside. Now that I compressed my final version of config I lost the useful comments.

As you mention there "do not use it unchanged" is a but unusual, so it would better to start with a working minimal example and the rest commented... but ok, let's start:

My compressed version:

```
use Sys::Hostname;

my $hostname = ($ENV{'HOSTNAME'} // hostname());

@order = qw(overlayfs aufs! unionfs-fuse! unionfs??# funionfs??#);

my $defaults = {

   COMPRESSION => 'lz4',

   COMPOPT_LZ4 => '',

};

my $non_binary = {

   COMPOPT_XZ => undef # "-Xbcj x86" is slower for pure text archives

};

@mounts = (

   standard_mount('adobe',            '/opt/Adobe',         $defaults),

   standard_mount('firefox',         '/usr/lib/firefox',      $defaults),

   standard_mount('icedtea6',         '/usr/lib/icedtea6',   $defaults),

   standard_mount('icedtea7',         '/usr/lib/icedtea7',   $defaults),

   standard_mount('layman',         '/var/lib/layman',      $defaults),

   standard_mount('libreoffice',      '/usr/lib/libreoffice',   $defaults),

   standard_mount('local_portage',      '/usr/local/portage',   $defaults),

   standard_mount('vmware',         '/opt/vmware',         $defaults),

    standard_mount('db',            '/var/db',            $defaults),

   standard_mount('tex', '/usr/share/texmf-dist', $defaults, $non_binary, {

      DIFF => [

         qr{^ls-R$},

         qr{^tex(?:/generic(?:/config(?:/language(?:\.(?:dat(?:\.lua)?|def)))?)?)?$}

      ]

   }),

   standard_mount('portage', '/usr/portage', $defaults, $non_binary, {

      UMOUNT => ((@umount) ? undef : '-i'),

      THRESHOLD => '80m',

      FILL => qr{^local/(?!(?:\.git|profiles|metadata)(?:/|$))}

   })

);

'EOF';
```

I disabled the old squash_dir setup by copying all squashed data back, so starting from scratch. But squashmount start fails for all items:

```
$ squashmount start -v

 * [adobe]:         It seems this is mounted for the first time:

                    The squashed file /opt/Adobe.mount/Adobe.sfs does not exist yet;

                    it will be initialized now from /opt/Adobe

Could not create destination file: No such file or directory

 * [adobe]:         error:   failed: /usr/bin/mksquashfs /opt/Adobe /opt/Adobe.mount/Adobe.sfs -noappend -quiet -comp lz4
```

PS.: It seems that app-arch/lz4 is there but Kernel support was missing. Now I have lz4 modules loaded but start is still failing for mksquashfs.

----------

## mv

 *Massimo B. wrote:*   

> Please make the config file configurable

 

I do not know what you mean by that. There are options to add additional config files, but they cannot be used reasonably by the default /etc/init.d files (or the default systemd units, respectively).

 *Quote:*   

> Because lot of the example is enabled which I don't need, it is harder to keep the example and merging new changes.

 

Yes, but this is normal for complex configuration files: You have similar issues with cups, wwwoffle, ssh, mtools, tor, privoxy, nvidia, ... even for some files in /etc/cron.*, /etc/modules.load.d, /etc/logrotate.d

 *Quote:*   

> You could also place some /etc/squashmount.pl.example beside.

 

You can just make a copy for yourself.

There is now a USE=example which installs into /etc/squashmount-example.pl, but I am not sure whether this is a good idea. Maybe this will be removed, again.

 *Quote:*   

> COMPRESSION => 'lz4'

 

Unless you patched the kernel manually, you will not be happy with that: Mounting will fail...

[quote]error:   failed: /usr/bin/mksquashfs /opt/Adobe /opt/Adobe.mount/Adobe.sfs -noappend -quiet -comp lz4[/code]

Ah, I see: This command is "correct", but it fails because /opt/Adobe.mount does not exist. Of course, such things usually happen only on the first installation and thus are not found in a "normal" debugging procedure.

squashmount-8.4 now generates the corresponding parent files in advance.

 *Quote:*   

> It seems that app-arch/lz4 is there but Kernel support was missing.

 

That's the problem: You can squash and (manually) unsquash with lz4, but you cannot use lz4 "regularly" unless you patch the kernel.

The kernel patch exists since almost a year (since lz4 is in the kernel), and it is only a few lines, but some kernel developer refused it with the stupid claim that it be not necessary that squashfs can compress quickly. I hope that the patch will be included, finally, but I am not very optimistic, meanwhile.

----------

## Massimo B.

 *mv wrote:*   

>  *Massimo B. wrote:*   Please make the config file configurable I do not know what you mean by that.

 

I meant an option to choose the config file, maybe via /etc/conf.d/squashmount. But maybe this is not the best idea either. For now I need to copy a new /etc/squashmount.pl behind of etc-update to keep my config and still get some new examples.

 *mv wrote:*   

>  *Quote:*   Because lot of the example is enabled which I don't need, it is harder to keep the example and merging new changes. Yes, but this is normal for complex configuration files: You have similar issues with cups, wwwoffle, ssh, mtools, tor, privoxy, nvidia, ... even for some files in /etc/cron.*, /etc/modules.load.d, /etc/logrotate.d

 

I know. But the thing with squashmount.pl is a bit different. The default and almost commented configurations like dnsmasq, privoxy etc. are working like this. But the squashmount.pl is absolutely required to be edited for not breaking things (it would start to squash otherwise..).

Then as I mentioned some time ago it feels a bit unusual to have real Perl code as config. Even some Perl colleagues on #perl have been surprised. But I see it is very powerful but also dangerous. No config will be comparable to others as Perl code can have very different styles. But leave it like this, it is powerful and I don't have a different idea..

 *mv wrote:*   

> There is now a USE=example which installs into /etc/squashmount-example.pl, but I am not sure whether this is a good idea. Maybe this will be removed, again.

 

Maybe just leave it in /usr/share/doc/squashmount-*.

 *mv wrote:*   

> Unless you patched the kernel manually, you will not be happy with that: Mounting will fail...

 

I don't prefer too much kernel patching as there already are some patches I'm using, like sys-fs/aufs3. Then I'm using sys-kernel/ck-sources. Is there an ebuild to do the patching? I'm quite interested in plain lz4 after reading your compress.txt benchmarks. Performance is more important than size. Even on recent platforms Portage is still very slow due to its architecture and physical drives (no SSD).

BTW, how did you measure the time, like 4 (lz4) vs. 3:50 (xz) for /var/db on Core2?

So for testing I switched all to old gzip now:

 *mv wrote:*   

> Ah, I see: This command is "correct", but it fails because /opt/Adobe.mount does not exist. Of course, such things usually happen only on the first installation and thus are not found in a "normal" debugging procedure.
> 
> squashmount-8.4 now generates the corresponding parent files in advance.

 

Thanks for the bugfix, pulled and working better, but still not successful. Starting from scratch with only one item:

```
$ squashmount -vvv start

 * squashmount: reading config file /etc/squashmount.pl

 * [adobe]: It seems this is mounted for the first time:

            The squashed file /opt/Adobe.mount/Adobe.sfs does not exist yet;

            it will be initialized now from /opt/Adobe

/usr/bin/mksquashfs /opt/Adobe /opt/Adobe.mount/Adobe.sfs -noappend -quiet -comp gzip

[=======================================================================================================

=====================================/] 1285/1285 100%

/sbin/modprobe squashfs

/bin/mount -t squashfs -o loop,ro,noatime -- /opt/Adobe.mount/Adobe.sfs /root/tmp/EgZI8WpycJ

/bin/umount -- /root/tmp/EgZI8WpycJ

 * [adobe]: cleaning original DIR

 * [adobe]: cleaning /opt/Adobe

 * [adobe]: mounting...

 * [adobe]: error:   no directory /opt/Adobe.mount/readonly
```

Admin edit: Added line break to long line of "=" characters. --pjp

----------

## mv

 *Massimo B. wrote:*   

> I meant an option to choose the config file, maybe via /etc/conf.d/squashmount.

 

Installing a config-file to get the location of the config-file? This sounds very wrong. Moreover, for systemd you would have to modify the unit, if you want to have this (unless you make the unit very non-systemd-ish). But of course, nobody prevents you from adding the option to your path to the systemd unit or to the init-file; such customizations are nothing which should be covered by an ebuild.

 *Quote:*   

> But the thing with squashmount.pl is a bit different. The default and almost commented configurations like dnsmasq, privoxy etc. are working like this. But the squashmount.pl is absolutely required to be edited for not breaking things (it would start to squash otherwise..).

 

No, dnsmasq, privoxy, tor etc will not do anything useful if you do not edit the config first (sshd will, but in a rather insecure way, so leaving the default is no good idea, either), mtools will even just print an error message (at least, it used to - not checked recently). Also squashmount will just print an error message and not start squashing. So I do not see much difference.

 *Quote:*   

> Then as I mentioned some time ago it feels a bit unusual to have real Perl code as config. Even some Perl colleagues on #perl have been surprised.

 

Sourcing in a separate namespace is one of the official perl recommendations for config files for perl-projects. (I read it at several places, among them some FAQ about why there is no analogue for python's ConfigParser.)

Also, it seems very clean and not hackish to me. It would be different, if the sourcing would happen in the main:: namespace (or if you need compatibility with a non-perl-tool, of course).

Also /etc/conf.d is arbitrary shell code, and I consider this as one of the main advantages of openrc, so that you can have the identical configurations for several machines and different situations - the configuration itself being conditional with user-defined conditions. (Also systemd provides such conditions, but they are much more limited and cannot be used everywhere).

Just now when the wish for a runtime-defined path (for mounting a CD into a chroot) was mentioed, I see that this decision is absolutely correct.

 *Quote:*   

> No config will be comparable to others as Perl code can have very different styles.

 

It is not necessary to compare configs. If currently chosen data must be mailed, you can use 

```
squashmount -vv list
```

 *Quote:*   

> Maybe just leave it in /usr/share/doc/squashmount-*.

 

At first, I also thought that this is the better idea, but then you would not see changes (not only etc-update will fail, but the previous config-file is not there at all).

 *Quote:*   

> Is there an ebuild to do the patching?

 

I don't know, and I will not spent my time to manage one. However, once that patch is in upstream kernel (or at least gentoo-sources or hardened-souces), probably the defaults in squashmount will change to lz4; this was announced here already several times...

 *Quote:*   

> Performance is more important than size.

 

Note that these benchmarks only involve the compression speed. Benchmarking decompression speed is not so easy, and this is what counts during using such a filesystem. I would guess that concerning decompression speed, the difference is not so much. Actually, xz might be superior here, since a shorter size means less disk acces and better caching possibilities.

 *Quote:*   

> BTW, how did you measure the time, like 4 (lz4) vs. 3:50 (xz) for /var/db on Core2?

 

Not too much effort was spent to make it very reliable: After verifying that no cron job will happen, essentially just

```
time mksquash /var/db ...
```

on the corresponding system, usually averaged over some calls to eliminate effects of caching/daemons. It was mainly to get an idea which options to use as default and whether perhaps on some systems there is a different order of the algorithms concerning speed (it seems not). However, once the list existed, why not make it available for eveybody.

 *Quote:*   

> Starting from scratch with only one item:

 

I did the same for testing, and it worked flawlessly. The only thing which I can imagine that might have happened in your case is that you once mounted (or almost mounted) and then removed the */readonly directory again: In this case, squashmount might have stored the existence of that directory for the mount-point adobe in /run/squashmount and thus did not check its existence again. Perhaps there should be a (usually redundant) check in squashmount for such a case.

----------

## Massimo B.

 *mv wrote:*   

> Also /etc/conf.d is arbitrary shell code, and I consider this as one of the main advantages of openrc, so that you can have the identical configurations for several machines and different situations - the configuration itself being conditional with user-defined conditions. (Also systemd provides such conditions, but they are much more limited and cannot be used everywhere).

 OT: That I agree, I definitly like having the same configurations over my machines to be able to merge changes. Currently I only have that for my large /etc/vim/vimrc.local with hostname conditions. But how do you do these conditions for other conf.d stuff?

Hm, again I start from scratch. The caching of old config data should be reset by squashmount reset, no? Where are they stored and why? The .new is just my backup:

```
$ ls -ald /opt/Adobe*

drwxr-xr-x 3 root root 4,0K Aug 21 09:37 /opt/Adobe/

drwxr-xr-x 3 root root 4,0K Aug 21 09:37 /opt/Adobe.new/

$ squashmount -vv list                                  ## I like that

 * [adobe]: not mounted

            DIR: /opt/Adobe

            READONLY: /opt/Adobe.mount/readonly

            CHANGES: /opt/Adobe.mount/changes

            WORKDIR: /opt/Adobe.mount/workdir

            FILE: /opt/Adobe.mount/Adobe.sfs

            mksquashfs options: -noappend -quiet -comp gzip

            CHMOD: 0644

            CHOWN: unchanged (0:0)

$ squashmount reset

 * [adobe]: resetting configuration

$ squashmount start

 * [adobe]: It seems this is mounted for the first time:

            The squashed file /opt/Adobe.mount/Adobe.sfs does not exist yet;

            it will be initialized now from /opt/Adobe

[=======================================================================================/] 1285/1285 100%

 * [adobe]: cleaning original DIR

 * [adobe]: mounting...

 * [adobe]: error:   no directory /opt/Adobe.mount/readonly
```

What I'm doing wrong here?

----------

## Massimo B.

As for the benchmarks, here is a decompression only benchmark. However in times when there is enough CPU but the physical drives are still slow, it could be a completely different result in real-life. I guess I will check with some Portage scenarios and different compressions. Speeding up portage is highest priority. I still remember best results with /var/db on some ancient reiserfs.

----------

## mv

 *Massimo B. wrote:*   

> The caching of old config data should be reset by squashmount reset, no?

 

No: You are looking for "squashmount forget". "squashmount reset" essentially just "undo's" the effect of some "squsahmount set" - in your current stage, this is irrelevant.

 *Quote:*   

> Where are they stored and why?

 

They are stored in /run/squashmount/adobe (in your case), but do not rely on that for future version of squashmount.

"squashmount forget" will remove this file if it is safe to do this.

They must be stored, because you might use a temporary directory (with a random, i.e. non-predictable name): once that directory is initialized, it should be reused, of course.

----------

## mv

In squashmount-8.5 a nonexistent stored directory is now considered as non-stored, that is it becomes recreated (possibly under a new temporary name): This is secure and is probably what users expect to happen in such a case.

In particular, this should fix the previous issue where "invalid" directories were stored "by mistake".

----------

## mv

Oh, I missed this question:

 *Massimo B. wrote:*   

> But how do you do these conditions for other conf.d stuff?

 

As I said, it is just usual (POSIX) shell code. For instance, I have in my net configuration stuff like 

```
if ! test -r /etc/firewall.d/dhcp-client

then

   config_lan0="...."

fi

...

if test -f /etc/ppp/my-username

then

   read username_ppp0 </etc/ppp/my-username

fi

...
```

Here, I use special "magic" files to switch between certain configuration settings or to keep my "secrets" off the configuration, respectively.

Of course, you can also make conditions based on hostname or on the content of a single file or whatever is appropriate for you to distinguish your configurations.

----------

## mv

 *Massimo B. wrote:*   

> As for the benchmarks, here is a decompression only benchmark

 

Such benchmarks have to be read with care: They cannot measure the actual disk access needed for squashfs. In fact, the latter can heavily vary with the type of directory you are using with squashfs and, even more, depends on your RAM and cache size, especially if you use memory (due to cache) hungry tools like portage.

----------

## Massimo B.

 *mv wrote:*   

> "squashmount forget" will remove this file if it is safe to do this.
> 
> They must be stored, because you might use a temporary directory (with a random, i.e. non-predictable name): once that directory is initialized, it should be reused, of course.

 

I don't understand that exactly, what is a temporary directory with a non-predictable name? Target dirs such as /opt/Adobe or /usr/portage won't change. Then I see that squashmount stop also runs a forget, so the cached information is only while squashmount is up, but with all squashfs mounted the directories won't change at all in the background, no?

It is still not working:

```
$ squashmount forget

 * [adobe]: forgetting settings

$ squashmount -vvv start

 * squashmount: reading config file /etc/squashmount.pl

 * [adobe]: mounting...

/sbin/modprobe squashfs

/bin/mount -t squashfs -o loop,ro,noatime -- /opt/Adobe.mount/Adobe.sfs /opt/Adobe.mount/readonly

/sbin/modprobe overlayfs

modprobe: FATAL: Module overlayfs not found.

/bin/mount -t overlayfs -o noatime -o 'upperdir=/opt/Adobe.mount/changes' -o 'lowerdir=/opt/Adobe.mount/readonly' -o 'workdir=/opt/Adobe.mount/workdir' -- overlayfs /opt/Adobe

mount: unknown filesystem type 'overlayfs'

 * [adobe]: warning: overlayfs failed

/sbin/modprobe aufs

/bin/mount -t aufs -o noatime -o 'br:/opt/Adobe.mount/changes=rw:/opt/Adobe.mount/readonly=rr' -- aufs /opt/Adobe

$ squashmount -vv list

 * [adobe]: aufs

            unmodified

            THRESHOLD: 0

            DIR: /opt/Adobe

            READONLY: /opt/Adobe.mount/readonly

            CHANGES: /opt/Adobe.mount/changes

            FILE: /opt/Adobe.mount/Adobe.sfs

            mksquashfs options: -noappend -quiet -comp gzip

            CHMOD: 0644

            CHOWN: unchanged (0:0)
```

It tries to use overlayfs (how do I get that, can't find in the kernel, some secret patches too?). But I still have aufs3 working. squashmount tries overlayfs anyway and fails.

BTW. sometime in the future we could start a squashmount only thread and link here. This thread is living since the original approach, then came squash_dir, and now squashmount. On a dedicated squashmount thread you could maintain the first #1 post to have a recent overwiew about the project.

----------

## Massimo B.

 *mv wrote:*   

> They cannot measure the actual disk access needed for squashfs. In fact, the latter can heavily vary with the type of directory you are using with squashfs and, even more, depends on your RAM and cache size, especially if you use memory (due to cache) hungry tools like portage.

 Therefore I'm going to check time for some portage scenario. After re-compressing with a different COMPRESSION, disk caching should not affect the result.

----------

## mv

 *Massimo B. wrote:*   

> I don't understand that exactly, what is a temporary directory with a non-predictable name?

 

For example, you could have used File::Temp::newdir() to get the name originally. Or you could have used an option like -a to set the name once (see the details in the ADVANCED CONFIGURATION section): It is intentional that the name does not change "on the fly".

 *Quote:*   

> Then I see that squashmount stop also runs a forget, so the cached information is only while squashmount is up

 

Yes, that's the idea. The content of /run is lost anyway once you boot new (which is normally the period in which squashmount is up; in most cases when you call squashmount manually you should use "squashmount mount/remount/umount" and not "squasmount start/restart/stop").

Since squashmount does not rely on the init system to manage the mounted directories, it manages them in /run/squashmount. It is necessary to manage also half-mounted states, e,g, if umount of DIR succeeds but the subsequent umount of READONLLY fails etc.

In particular, squashmount stores directories like READONLY or CHANGES in /run only after it created them.

So it seemed safe to rely that they exist when these directories are stored.

But you proved that this is not safe: What happened in your case was presumably that you called "squashmount start" which returned with some failure, but only after it created the READONLY and CHANGES directories and stored that information. Then you did remove this directory, making the stored information "false".

In squashmount-8.5 this is "fixed" by verifying that the stored direectories actually exist, and if they do not to consider the stored information as invalid (hence act, as if that information is not stored, that is, in your case, create the directory). In a sense, due to this fix, squashmount thus now wants to be smarter than the user, but I think in this case this can do no harm.

 *Quote:*   

> squashmount tries overlayfs anyway and fails.

 

No, squashmount did not fail: It mounted succesfully with aufs and returned succesfully.

I suppose that IO-Uncompress-Gunzip is installed, but your /proc/config.gz is not readable, since otherwise squashmount would have scanned that file to find that overlayfs is not configured for your kernel. (If this is not the case, you have found a bug in squashmount, and in this case please inform me, whether /proc/config.gz is readable and/or IO-Uncompress-Gunzip is installed).

This is the documented beviour of the default @order=qw(overlayfs? aufs! ...):

It first modprobes overlayfs, and if that fails, it checks for overlay in /proc/config.gz, assuming a positive result if the latter check fails. If you want to assume a negative result if the latter check fails, you have to use ?? instead of ?, i.e. 

```
$order[0]='overlayfs??';
```

(or e.g. shift @order if you want to skip completely all checks for overlayfs and immediately try aufs).

 *Quote:*   

> sometime in the future we could start a squashmount only thread and link here.

 

A few users will miss the new thread, and then there will actually be two threads...   :Sad: 

----------

## Massimo B.

 *mv wrote:*   

> I suppose that IO-Uncompress-Gunzip is installed, but your /proc/config.gz is not readable, since otherwise squashmount would have scanned that file to find that overlayfs is not configured for your kernel. (If this is not the case, you have found a bug in squashmount, and in this case please inform me, whether /proc/config.gz is readable and/or IO-Uncompress-Gunzip is installed).

 What is IO-Uncompress-Gunzip? Kernel option? However my config.gz is readable:

```
$ zgrep GZIP /proc/config.gz

CONFIG_HAVE_KERNEL_GZIP=y

CONFIG_KERNEL_GZIP=y

CONFIG_RD_GZIP=y

CONFIG_DECOMPRESS_GZIP=y

$ ls -al /proc/config.gz

-r--r--r-- 1 root root 19K Aug 22 14:24 /proc/config.gz
```

Maybe it is not up-to-date, because I added some modules later without restart?

Weird, squashfs is mounted quickly, but as I mentioned some time ago, aufs takes very long, ~20s. For 10 mounts this takes very long at boot.

What is the preferred backend setup for squashmount with the optimal that is only few kernel patches?

----------

## Massimo B.

 *mv wrote:*   

> With squashmount you can do it on the fly: 
> 
> ```
> squashmount -fsx xz remount
> ```
> ...

 BTW. I tried recompressing to test some COMPRESSIONs, but there is no recompression done:

```
$ squashmount -fsx xz remount

 * [adobe]: umounting...

 * [adobe]: cleaning changes...

 * [adobe]: mounting...

$ squashmount -fsx gzip remount

 * [adobe]: umounting...

 * [adobe]: cleaning changes...

 * [adobe]: mounting...
```

Same if changing the squashmount.pl config and forcing remount.

----------

## Lomaxx

Hello.

I've been using squashmount for quite some while by now. Since i did a world-update (including kernel-update) yesterday, i first broke my aufs-support, then repaired it and now have got it working again, BUT with an annoying delay while booting that I didn't experience before. The delay is altogether roughly 5-10 seconds long for 3 squashed directories (portage/db/layman), i do not receive any errors while booting and i wonder what might be causing it. Before there was no delay at all.

 If someone got a close guess it would help me somewhat. Otherwise I have to try to solve it by trial and error.

Some info on my system:

- sys-kernel/aufs-sources-3.16.1

- sys-fs/aufs-headers-3.16_p20140818:0

- sys-fs/aufs-util-3.16_p20140818:0

- sys-fs/squashfs-tools-4.2-r1:0

- sys-fs/squashmount-6.0a:0

Kernel-Config regarding aufs:

CONFIG_AUFS_FS=y

CONFIG_AUFS_BRANCH_MAX_127=y

# CONFIG_AUFS_BRANCH_MAX_511 is not set

# CONFIG_AUFS_BRANCH_MAX_1023 is not set

# CONFIG_AUFS_BRANCH_MAX_32767 is not set

CONFIG_AUFS_SBILIST=y

# CONFIG_AUFS_HNOTIFY is not set

# CONFIG_AUFS_EXPORT is not set

# CONFIG_AUFS_FHSM is not set

# CONFIG_AUFS_RDU is not set

# CONFIG_AUFS_SHWH is not set

# CONFIG_AUFS_BR_RAMFS is not set

# CONFIG_AUFS_BR_FUSE is not set

CONFIG_AUFS_BDEV_LOOP=y

# CONFIG_AUFS_DEBUG is not set

extracts from squashmount.pl:

#!/usr/bin/perl (this is only for editors)

@order = qw(aufs! unionfs-fuse! unionfs??# funionfs??#);

my $defaults = {

	COMPRESSION => 'xz', # We could omit this line as xz is default.

	                     # However, this might change in the future

	COMPOPT_LZ4 => '-Xhc', # We could omit this line as -Xhc is default

	COMPOPT_XZ => ['-Xbcj', 'x86'] # Use this in case COMPRESSION => 'xz'

};

my $non_binary = {

	COMPOPT_XZ => undef # "-Xbcj x86" is slower for pure text archives

};

@mounts = (

	added_hash($defaults, $non_binary,  {

		TAG => 'db',

		DIR => '/var/db',

		FILE => '/var/db.sqfs',

		BACKUP => '.bak', # keep a backup in /var/db.sqfs.bak

		             # For an absolute path, we could have written:

		             # BACKUP => '/backup-disk/db.sqfs'

		CHANGES => '/var/db.changes',

		READONLY => '/var/db.readonly',

		THRESHOLD => '30m',

		BLOCKSIZE => 65536

	}),

	added_hash($defaults, $non_binary,  {

		TAG => 'layman',

		DIR => '/var/lib/layman',

		FILE => '/var/lib/layman.sqfs',

		BACKUP => '.bak', # keep a backup in /var/db.sqfs.bak

		             # For an absolute path, we could have written:

		             # BACKUP => '/backup-disk/db.sqfs'

		CHANGES => '/var/lib/layman.changes',

		READONLY => '/var/lib/.readonly',

		THRESHOLD => '30m',

		BLOCKSIZE => 65536

	}),

	standard_mount('portage', '/usr/portage', $defaults, $non_binary, {

		THRESHOLD => '80m',

		FILL => qr{^local/(?!(\.git|profiles|metadata)(/|$))}

	}),

);

As a solution I thought about rebuilding the directories freshly or enabling the userspace-option in the kernel, but haven't tried that yet. Any help would be appreciated.

----------

## Lomaxx

Out of curiosity i measured the times and noticed that my 5-10-seconds-guess was a bit underestimated:

Each directory takes 15 seconds to mount although their sizes differ.

So in total it takes 45 seconds.

$ ls -l /usr/portage.sqfs 

-rw-r--r-- 1 root root 76918784 22. Aug 15:49 /usr/portage.sqfs

$ ls -l /var/db.sqfs 

-rw-r--r-- 1 root root 31797248 22. Aug 15:48 /var/db.sqfs

$ ls -l /var/lib/layman.sqfs 

-rw-r--r-- 1 root root 11046912 29. Mai 14:19 /var/lib/layman.sqfs

CPU is a Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz with 16GB ram.

----------

## mv

Massimo B., thanks for testing. There was a regression in an apparently trivial code change in v7.6 (a negation was missing) so that the detection of IO::Uncompress::Gunzip was inverted.

 *Massimo B. wrote:*   

> What is IO-Uncompress-Gunzip?

 

A perl module. It is part of virtual/perl-IO-Compress in gentoo and contained in >perl-5.9

 *Quote:*   

> BTW. I tried recompressing to test some COMPRESSIONs, but there is no recompression done

 

It is not possible to force recompression if CHANGES is empty: --force only forces a remount, and -s only ignores threasholds which might apply. I think it is not necessary to have a special option which is useful only for "benchmarking".

----------

## mv

 *Lomaxx wrote:*   

> BUT with an annoying delay while booting

 

You are not the first one who reports a delay with aufs. It seems to be a problem of recent aufs versions.

----------

## Lomaxx

@mv: Good to know, bad to suffer.  :Wink:  Thanks for the feedback. If no cure is known, then I will fiddle around and report back in case i find a solution.

----------

## Massimo B.

Beside all the patching around compression like LZ4 and overlayfs/aufs, can you give a short overview what is supported by main line kernels, what is easy to patch / add as userspace tools, and what is known to be broken or fiddly.

BTW. looking for backup strategies I got to know one more time btrfs, supporting transparent compression, incrementing snapshots, subvolumes etc. This would ease a lot of single mounts with squashmount, however btrfs is said to be still experimental although some enterprise linux has enabled this officially.

----------

## mv

 *Massimo B. wrote:*   

> can you give a short overview what is supported by main line kernels

 

The current state is easy:

Concerning squashfs, everything is supported except lz4.

Concerning making it read-writable: The only supported solution is unionfs-fue (or funionfs, but that does not seem to be maintained anymore). Neither aufs nor overlayfs are supported.

Of course, there are patches, but they are not mainline, and I cannot predict whether some will go mainline eventually. I would expect that squashfs-lz4 and overalyfs are the first to become mainline, but this is a wild guess.

 *Quote:*   

> BTW. looking for backup strategies I got to know one more time btrfs, supporting transparent compression, incrementing snapshots, subvolumes etc.

 

I would not risk to use it now. Moreover, I heard it behaves not well on full disks.

What is even more important: All "online" compressions are necessarily rather suboptimal since you need a huge amount of data before you can compress well. For typical implementations this means that compression ratio is extremely poor for many small files. So for PORTDIR and /var/db, there will hardly be anything better than squashfs.

----------

## Massimo B.

Thanks for your opinion about btrfs making things clearer.

Adding new squashes still does not work:

```
$ squashmount -vvvvv umount

 * squashmount: reading config file /etc/squashmount.pl

 * [adobe]:    umounting...

/bin/umount -v -- /opt/Adobe

umount: /opt/Adobe (unionfs) unmounted

/bin/umount -v -- /opt/Adobe.mount/readonly

umount: /opt/Adobe.mount/readonly (/dev/loop0) unmounted

 * [adobe]:    cleaning changes...

 * [adobe]:    cleaning /opt/Adobe.mount/changes

 * [icedtea6]: error:   not mounted

$ squashmount forget

 * [adobe]:    forgetting settings

 * [icedtea6]: forgetting settings

$ squashmount reset

 * [adobe]:    resetting configuration

 * [icedtea6]: resetting configuration

$ squashmount -vvvvv mount

 * squashmount: reading config file /etc/squashmount.pl

 * [adobe]:    mounting...

/sbin/modprobe -v squashfs

/bin/mount -t squashfs -o loop,ro,noatime -v -- /opt/Adobe.mount/Adobe.sfs /opt/Adobe.mount/readonly

mount: /dev/loop0 mounted on /opt/Adobe.mount/readonly.

/sbin/modprobe -v fuse

/usr/bin/unionfs -o cow -o allow_other -o use_ino -o nonempty -o noatime -o hide_meta_files '/opt/Adobe.mount/changes=RW:/opt/Adobe.mount/readonly=RO' /opt/Adobe

 * [icedtea6]: error:   squashfile /usr/lib64/icedtea6.mount/icedtea6.sfs not found
```

So I go for sys-fs/unionfs-fuse now, eventhough aufs3 seems to be the better choice due to Knoppix. I changed to 

```
#@order = qw(overlayfs aufs! unionfs-fuse! unionfs??# funionfs??#);

#@order = qw(aufs);

@order = qw(unionfs-fuse);
```

Switching to unionfs-fuse worked by remount, but the mounting still takes ~30s right after the squashfs:

```
$ squashmount -fs -vvv remount

 * squashmount: reading config file /etc/squashmount.pl

 * [adobe]:    umounting...

/bin/umount -- /opt/Adobe

/bin/umount -- /opt/Adobe.mount/readonly

 * [adobe]:    cleaning changes...

 * [adobe]:    cleaning /opt/Adobe.mount/changes

 * [adobe]:    mounting...

/sbin/modprobe squashfs

/bin/mount -t squashfs -o loop,ro,noatime -- /opt/Adobe.mount/Adobe.sfs /opt/Adobe.mount/readonly

### LONG TIME DELAY ###

/sbin/modprobe fuse

/usr/bin/unionfs -o cow -o allow_other -o use_ino -o nonempty -o noatime -o hide_meta_files '/opt/Adobe.mount/changes=RW:/opt/Adobe.mount/readonly=RO' /opt/Adobe

 * [icedtea6]: error:   not mounted
```

----------

## mv

 *Massimo B. wrote:*   

> Adding new squashes still does not work

 

If you want to create a new squashfile, you have to use "create" (or "start"), not "mount": Mount intentionally performs only "safe" operations (deleting directories recursively is always somewhat dangerous, no matter how many sanity checks are done first).

 *Quote:*   

> eventhough aufs3 seems to be the better choice

 

It certainly is, but the disadvantage are the kernel patches. Personally, I use overlayfs and unionfs-fuse as a fallback. But sometimes I also use aufs and unionfs-fuse as a fallback. It depends which kernel patches I get earlier and install without problems. aufs always has problems with hardened-souces since it wants to hack a function pointer list which is readonly in hardened.

 *Quote:*   

> /bin/mount -t squashfs -o loop,ro,noatime -- /opt/Adobe.mount/Adobe.sfs /opt/Adobe.mount/readonly
> 
> ### LONG TIME DELAY ###

 

So in your case it is probably squashfs which takes so long to mount. I never had a long delay here. Is this file paricularly large? Or maybe it is too much "spread" on your harddisk. Maybe it helps to run a defragmentation utility for the underlying filesystem.

----------

## Massimo B.

 *mv wrote:*   

> So in your case it is probably squashfs which takes so long to mount. I never had a long delay here. Is this file paricularly large? Or maybe it is too much "spread" on your harddisk. Maybe it helps to run a defragmentation utility for the underlying filesystem.

 

I don't think so. underlying filesystem is a some months old ext4:

```
$ ls -alh /opt/Adobe.mount/Adobe.sfs

-rw-r--r-- 1 root root 58M Aug 21 16:15 /opt/Adobe.mount/Adobe.sfs

$ filefrag /opt/Adobe.mount/Adobe.sfs

/opt/Adobe.mount/Adobe.sfs: 5 extents found
```

----------

## Massimo B.

Feature request: Is there a way to have THRESHOLD as relative levels like "0.2" (20%) or something? For binary only like /usr/lib/icedtea7 a change usually means recompression, so the default 0 is ok. But for dirs that are often changing like /var/db I usually like to have some relative level of difference instead of hard thresholds like 20 MB, no?

----------

## mv

 *Massimo B. wrote:*   

> Feature request: Is there a way to have THRESHOLD as relative levels like "0.2" (20%)

 

The problem of this is: 20% of "what"? squashmount would have to calculate the size of all files, and this would take a lot of time. Usually, one changes mount-points not very frequenty, and mount-points usually do not change their size dramatically. For instance, for /var/db, you will probably always have roughly the same number of packages installed - nothing which makes it worth to calculate the size for almost every run of squashmount.

----------

## Massimo B.

 *Massimo B. wrote:*   

> 
> 
> /bin/mount -t squashfs -o loop,ro,noatime -- /opt/Adobe.mount/Adobe.sfs /opt/Adobe.mount/readonly
> 
> ### LONG TIME DELAY ###

 I have no clue about this and squashmount is quite unusable with more than 1 or 2 mounts, so I opened a bug report. Please append information if you have more.

I also removed the modules and loaded again. I just wonder that it only dependy on xz_dec while I have all compressions enabled in the kernel config:

```
$ modinfo squashfs

filename:       /lib/modules/3.14.4-ck/kernel/fs/squashfs/squashfs.ko

license:        GPL

author:         Phillip Lougher <phillip@squashfs.org.uk>

description:    squashfs 4.0, a compressed read-only filesystem

alias:          fs-squashfs

depends:        xz_dec

intree:         Y

vermagic:       3.14.4-ck SMP preempt mod_unload

$ zgrep SQUASHFS /proc/config.gz |grep -v "^#"

CONFIG_SQUASHFS=m

CONFIG_SQUASHFS_FILE_DIRECT=y

CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU=y

CONFIG_SQUASHFS_ZLIB=y

CONFIG_SQUASHFS_LZO=y

CONFIG_SQUASHFS_XZ=y

CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3
```

----------

## mv

 *Massimo B. wrote:*   

> just wonder that it only dependy on xz_dec

 

ZLIB_DEFLATE and LZO_DECOMPRESS are probably hard compiled into the kernel (not as modules).

----------

## Massimo B.

True, those were hard compiled.

Weird, I got the mount delay problem fixed now , be resquashing everything, and using unionfs-fuse only. This should have been some aufs3 related issue though it did not look like...

----------

## mv

 *Massimo B. wrote:*   

> This should have been some aufs3 related issue though it did not look like...

 

I doubt it: It was squashfs which took so long too mount.

Perhaps the file order was unfortunate for you, but it is hard to believe that this makes such a huge difference.

----------

## Massimo B.

The delay at mount -t squashfs is back again. It appeared again when switching around with COMPRESSION lzo and gzip and remounting.

I also got to know that some "forget" and forced create also may drop the existing squashfs and loosing all data. So I should be careful with important data such as /var/db.

----------

## mv

 *Massimo B. wrote:*   

> I also got to know that some "forget" and forced create

 

Yes, this is an example where the sanity checks for the deletion in the "create" action are possibly insufficient. The "create" will create a non-empty squashfile, but the deletion afterwards might mark the data as deleted in CHANGES, so that the doubly-overmounted DIR becomes empty, and the next umount will store that empty DIR in the squashfile. Doubly overmounting just is a mess... this should not be able to happen if you do not use --force (there is a reason why there is a warning for it...)

----------

## Massimo B.

How do I preserve permissions in the squashfs? There is something wrong. I did chmod -R texlive:texlive /usr/local/texlive. Then after resquashing, the permissions are reset to root, and some updates I did before are lost. I guess the resquashing is failing somehow and some old squashfs is mounted. This time the mounting did take more than 10 minutes.

```
$ du -sh /usr/local/texlive /usr/local/texlive.mount/*

1,1G   /usr/local/texlive

4,0K   /usr/local/texlive.mount/changes

1,1G   /usr/local/texlive.mount/readonly

752M   /usr/local/texlive.mount/texlive.sfs

$ df -h /

Filesystem      Size  Used Avail Use% Mounted on

/dev/sda3        24G   19G  4,6G  81% /
```

----------

## mv

 *Massimo B. wrote:*   

> How do I preserve permissions in the squashfs?

 

Should be preserved automatically. (Of course, permissions of DIR and READONLY itself might change between mounted and umounted state).

 *Quote:*   

> Then after resquashing, the permissions are reset to root, and some updates I did before are lost

 

Did you perhaps use different tools? I mean: If you once mounted with aufs, did not resquash, and next time mount with unionfs-fuse there might be problems, because the format in CHANGES for these two tools are probably not compatible with each other.

----------

## Massimo B.

 *mv wrote:*   

> Did you perhaps use different tools? I mean: If you once mounted with aufs, did not resquash, and next time mount with unionfs-fuse there might be problems, because the format in CHANGES for these two tools are probably not compatible with each other.

 Could be. But at least after resquashing that conflict should be gone, no? Then the mount delay should only appear for some of the squashmounts, not for the already re-squashed.

Let's try with a really small /usr/share/texmf-dist (because I switched to a local /usr/local/texlive):

```
$ squashmount list -vvv texmf

 * squashmount: reading config file /etc/squashmount.pl

 * [texmf]:         unionfs-fuse

                    unmodified

                    THRESHOLD: 0

                    DIR: /usr/share/texmf-dist

                    READONLY: /usr/share/texmf-dist.mount/readonly

                    CHANGES: /usr/share/texmf-dist.mount/changes

                    FILE: /usr/share/texmf-dist.mount/texmf-dist.sfs

                    mksquashfs options: -noappend -quiet -comp gzip

                    CHMOD: 0644

                    CHOWN: unchanged (0:0)

$ squashmount status -vvv texmf

 * squashmount: reading config file /etc/squashmount.pl

 * [texmf]:         not mounted

                    DIR: /usr/share/texmf-dist

                    READONLY: /usr/share/texmf-dist.mount/readonly

                    CHANGES: /usr/share/texmf-dist.mount/changes

                    WORKDIR: /usr/share/texmf-dist.mount/workdir

                    FILE: /usr/share/texmf-dist.mount/texmf-dist.sfs

                    mksquashfs options: -noappend -quiet -comp gzip

                    CHMOD: 0644

                    CHOWN: unchanged (0:0)

$ du -sh /usr/share/texmf-dist /usr/share/texmf-dist.mount/*

4,0K   /usr/share/texmf-dist

4,0K   /usr/share/texmf-dist.mount/changes

4,0K   /usr/share/texmf-dist.mount/readonly

396K   /usr/share/texmf-dist.mount/texmf-dist.sfs

4,0K   /usr/share/texmf-dist.mount/workdir

$ squashmount mount -vvv texmf

 * squashmount: reading config file /etc/squashmount.pl

 * [texmf]:         mounting...

/sbin/modprobe squashfs

/bin/mount -t squashfs -o loop,ro,noatime -- /usr/share/texmf-dist.mount/texmf-dist.sfs /usr/share/texmf-dist.mount/readonly

### DELAY ###

/sbin/modprobe fuse

/usr/bin/unionfs -o cow -o allow_other -o use_ino -o nonempty -o noatime -o hide_meta_files '/usr/share/texmf-dist.mount/changes=RW:/usr/share/texmf-dist.mount/readonly=RO' /usr/share/texmf-dist

$ du -sh /usr/share/texmf-dist /usr/share/texmf-dist.mount/*

4,1M   /usr/share/texmf-dist

4,0K   /usr/share/texmf-dist.mount/changes

4,1M   /usr/share/texmf-dist.mount/readonly

396K   /usr/share/texmf-dist.mount/texmf-dist.sfs

4,0K   /usr/share/texmf-dist.mount/workdir

$ touch /usr/share/texmf-dist/test && time squashmount remount -vvv texmf

 * squashmount: reading config file /etc/squashmount.pl

 * [texmf]:         squashing (this may take a while)

/usr/bin/mksquashfs /usr/share/texmf-dist /root/tmp/yb_MMvEReH -noappend -quiet -comp gzip

[==============================================================|] 114/114 100%

 * [texmf]:         umounting...

/bin/umount -- /usr/share/texmf-dist

/bin/umount -- /usr/share/texmf-dist.mount/readonly

 * [texmf]:         tempfile (/root/tmp/yb_MMvEReH) -> /usr/share/texmf-dist.mount/texmf-dist.sfs

 * [texmf]:         cleaning changes...

 * [texmf]:         cleaning /usr/share/texmf-dist.mount/changes

 * [texmf]:         mounting...

/sbin/modprobe squashfs

/bin/mount -t squashfs -o loop,ro,noatime -- /usr/share/texmf-dist.mount/texmf-dist.sfs /usr/share/texmf-dist.mount/readonly

### DELAY ###

/sbin/modprobe fuse

/usr/bin/unionfs -o cow -o allow_other -o use_ino -o nonempty -o noatime -o hide_meta_files '/usr/share/texmf-dist.mount/changes=RW:/usr/share/texmf-dist.mount/readonly=RO' /usr/share/texmf-dist

real   0m39.822s

user   0m0.532s

sys   0m0.017s
```

----------

## mv

 *Massimo B. wrote:*   

> But at least after resquashing that conflict should be gone, no?

 

But at resquash only the information is squashed which you currently can see; if there was a conflict, you might have squashed the wrong data.

 *Quote:*   

> mount -t squashfs -o loop,ro,noatime -- /usr/share/texmf-dist.mount/texmf-dist.sfs /usr/share/texmf-dist.mount/readonly

 

For testing, you could mount manually with the above command (and umount manually) - this should be the cause for the delay for whatever reason. Another possibility is that it is not related with squashfs but with the mount command: I have util-linux-2.24.2 with the USE-flags "caps fdformat ncurses tty-helpers unicode" enabled. I suppose you have also pam and maybe something else. I never checked what mount actually does, but maybe with these additional useflags it might do something which waits for a timeout? Perhaps running strace with the above command gives a hint where the time is lost?

----------

## Massimo B.

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

```
lstat("/mnt/sd2dav.massimo.b",
```

I just forgot about that since the delay was also last time I restarted and that davfs2 is only mounted temporarilly on user space. First I need to get rid of that davfs2 before claiming about squashfs.

----------

## 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:

```
$ squashmount -vvv start

 * squashmount: reading config file /etc/squashmount.pl

 * [adobe]:         mounting...

/sbin/modprobe squashfs

/bin/mount -t squashfs -o loop,ro,noatime -- /opt/Adobe.mount/Adobe.sfs /opt/Adobe.mount/readonly

mount: /opt/Adobe.mount/readonly: mount failed: Unknown error -1

 * [adobe]:         error:   failed to mount squashfile

 * [firefox]:       mounting...

/bin/mount -t squashfs -o loop,ro,noatime -- /usr/lib64/firefox.mount/firefox.sfs /usr/lib64/firefox.mount/readonly

mount: /usr/lib64/firefox.mount/readonly: mount failed: Unknown error -1

 * [firefox]:       error:   failed to mount squashfile
```

Even mounting squashfs manually give the same error.

I even tried creating some new squashfs with default gzip and mounting of that fails the same.

```
$ lsmod |grep squash

squashfs               23672  0 

xz_dec                 10928  1 squashfs

$ zgrep "SQUASH" /proc/config.gz |grep -v "^#"

CONFIG_SQUASHFS=m

CONFIG_SQUASHFS_FILE_DIRECT=y

CONFIG_SQUASHFS_DECOMP_MULTI=y

CONFIG_SQUASHFS_ZLIB=y

CONFIG_SQUASHFS_LZO=y

CONFIG_SQUASHFS_XZ=y

CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3
```

Now I can't even emerge without db and portage. Is there a workaround? What is wrong with the kernel? Squashmount is using LZO for all mounts.

----------

## 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. 

```
cd /var/db.mount

unsquashfs db.sfs

mv /var/db /var/db.dup

mv squashfs-root /var/db
```

 and similarly for your portage tree.

If unsquashfs fails, you have a problem: In this case your squashfile is corrupted and your data is lost unless you have a backup.

Might it be that you were running out of disk space when you were squashing?  (squashmount checks the error codes, but maybe some modern filesystems do not report correctly when they are running out of disk space).

----------

## 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

----------

## 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.

----------

## mv

 *costel78 wrote:*   

> Has anyone tried yet squashmount with in-kernel built overlayfs (gentoo-sources-3.18.0)?

 

Originally, I wanted to wait with this until hardened-sources-3.18.* appeared. If I should find time earlier, I will do earlier.

 *Quote:*   

> I presume it's because cat /proc/filesystems show nodev	overlay instead overlayfs, or other tools are required.

 

From what you say it can mean that they require now mount -t overlay ... instead of mount -t overlayfs ...

If this is the case, squasmount needs to be updated, first. It is not clear to me yet how to do this without breaking compatibility with earlier overlayfs.

----------

## costel78

 *mv wrote:*   

> If this is the case, squasmount needs to be updated, first. It is not clear to me yet how to do this without breaking compatibility with earlier overlayfs.

 

Thank for answering. Overlay/overlayfs nomenclature seems to be problematic, indeed. I don't know how fast or reliable questioning /proc/filesystem is, but it was the quickest way for me.

----------

## 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.    :Smile: 

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

```
Dec 12 10:07:51 gentoo squashmount[1251]: * [portage]: mounting...

Dec 12 10:07:51 gentoo kernel: overlayfs: workdir and upperdir must reside under the same mount

Dec 12 10:07:51 gentoo squashmount[1251]: mount: wrong fs type, bad option, bad superblock on overlay,

Dec 12 10:07:51 gentoo squashmount[1251]: missing codepage or helper program, or other error

Dec 12 10:07:51 gentoo squashmount[1251]: In some cases useful info is found in syslog - try

Dec 12 10:07:51 gentoo squashmount[1251]: dmesg | tail or so.

Dec 12 10:07:51 gentoo squashmount[1251]: * [portage]: warning: overlay failed

Dec 12 10:07:51 gentoo squashmount[1251]: /usr/bin/which: no unionfs in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)

Dec 12 10:07:51 gentoo squashmount[1251]: * [portage]: error:   unionfs not found in $PATH

Dec 12 10:07:51 gentoo squashmount[1251]: * [portage]: warning: unionfs-fuse failed

Dec 12 10:07:51 gentoo squashmount[1251]: /usr/bin/which: no funionfs in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)

Dec 12 10:07:51 gentoo squashmount[1251]: * [portage]: error:   funionfs not found in $PATH

Dec 12 10:07:51 gentoo squashmount[1251]: * [portage]: warning: funionfs failed

Dec 12 10:07:51 gentoo squashmount[1251]: * [portage]: error:   fallback to mount --bind

Dec 12 10:07:51 gentoo squashmount[1251]: * [db]:      mounting...

Dec 12 10:07:51 gentoo squashmount[1251]: mount: wrong fs type, bad option, bad superblock on overlay,

Dec 12 10:07:51 gentoo squashmount[1251]: missing codepage or helper program, or other error

Dec 12 10:07:51 gentoo squashmount[1251]: In some cases useful info is found in syslog - try

Dec 12 10:07:51 gentoo squashmount[1251]: dmesg | tail or so.

Dec 12 10:07:51 gentoo kernel: overlayfs: workdir and upperdir must reside under the same mount

Dec 12 10:07:51 gentoo squashmount[1251]: * [db]:      warning: overlay failed

Dec 12 10:07:51 gentoo squashmount[1251]: * [db]:      error:   unionfs not found in $PATH

Dec 12 10:07:51 gentoo squashmount[1251]: * [db]:      warning: unionfs-fuse failed

Dec 12 10:07:51 gentoo squashmount[1251]: * [db]:      error:   funionfs not found in $PATH

Dec 12 10:07:51 gentoo squashmount[1251]: * [db]:      warning: funionfs failed

Dec 12 10:07:51 gentoo squashmount[1251]: * [db]:      error:   fallback to mount --bind
```

----------

## mv

 *costel78 wrote:*   

> it seems that something is wrong with mount options: workdir and upperdir must reside under the same mount

 

That's a restriction of "overlay": The error message means that WORKDIR and CHANGES must belong to the same partition ("upperdir" is what squashmount calls CHANGES).

If you use the default paths this should be the case (becaues they both belong to DIR.mount/...)

Maybe this error is caused because you tried to mount first with the old version of squashmount and could not properly umount?

I cannot reproduce this error here.

----------

## costel78

 *mv wrote:*   

> That's a restriction of "overlay": The error message means that WORKDIR and CHANGES must belong to the same partition ("upperdir" is what squashmount calls CHANGES).
> 
> If you use the default paths this should be the case (becaues they both belong to DIR.mount/...)
> 
> Maybe this error is caused because you tried to mount first with the old version of squashmount and could not properly umount?

 

Previous umount was successfully. Even with overlay not working umount is always successful.

To be sure, I test with no previous squashmount, on brand new portage and db dir on disk.

I do not know perl, but I make a backup of squashmount script and tried some "classic" debugging with print and overlay is right about the error:

```
Dec 12 15:04:11 mini squashmount[10325]: Workdir: /tmp/ra3n7kRDDc

Dec 12 15:04:11 mini squashmount[10325]: Changes: /var/db.changes, Read-Only: /var/db.readonly, WorkDir: /tmp/ra3n7kRDDc

Dec 12 15:04:11 mini squashmount[10325]: mount: wrong fs type, bad option, bad superblock on overlay,

Dec 12 15:04:11 mini squashmount[10325]: missing codepage or helper program, or other error

Dec 12 15:04:11 mini squashmount[10325]: In some cases useful info is found in syslog - try

Dec 12 15:04:11 mini squashmount[10325]: dmesg | tail or so.
```

In my configuration /tmp is mount on RAM as tmpfs - afaik that is default for systemd - and /var/db, /var/db.changes and /var/db.readonly are on /dev/sda2

----------

## mv

 *costel78 wrote:*   

> and /var/db, /var/db.changes and /var/db.readonly are on /dev/sda2

 

So you are using the "obsolete" defaults, not the current ones:

The defaults have changed to use /var/db /var/db.mount/changes /var/db.mount/readonly and /var/db.mount/workdir, respectively:

This change happened exactly, because overlayfs had this requirement concerning WORKDIR being on the same partition as CHANGES.

If you want to use overlay[fs], you should better specify WORKDIR explicitly.

----------

## 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!

----------

## 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.

----------

## mv

 *Massimo B. wrote:*   

> Hi, now that overlayfs is part of the 3.18 kernel and supported by squashmount as "overlay", is that now the preferred choice?

 

I guess so, at least until perhaps someday aufs will arrive in mainline kernel: In the moment overlay is taken by default if you have it and do not have modified @order.

 *Quote:*   

> I realised that http://overlays.gentoo.org/ is down for a while

 

AFAIK, only the web interface is down. You can still use the overlay with git.

----------

## Massimo B.

 *mv wrote:*   

> AFAIK, only the web interface is down. You can still use the overlay with git.

 I have some hosts in http restricted proxied networks, which is not that unusual. There also emerge-delta-webrsync is doing a good job, but always when it comes to git:// it is hard to solve (like Vim Addon Manager also relying mostly on git:// sources even when there are http:// alternatives around).

----------

## Massimo B.

 *mv wrote:*   

>  *Massimo B. wrote:*   I realised that http://overlays.gentoo.org/ is down for a while AFAIK, only the web interface is down. You can still use the overlay with git.

 mrueg told me he has mirrored his Overlay on github for that issue. Since I can't access your overlay on some machines, looking out for a http mirror, I found http://cgit.gentooexperimental.org/user/mv.git/ supposed to be maintained by xiaomiao, a quite up-to-date cgit interface. If this is reliable it could be an idea to ask layman if he would add this mirror as http-fallback for all overlays until overlays.gentoo.org is back.

----------

## 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

 *Quote:*   

> 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.

 

sorry to hear that but it is of course understandable.

Before i start messing around, what is actually the safest way to undo this setup ? 

TIA !!

----------

## mv

 *gringo wrote:*   

> Before i start messing around, what is actually the safest way to undo this setup?

 

Do you mean undoing squashmount or systemd?

For squashmount, you just quit using it.

For systemd, you don't need to do much: You can install openrc and systemd together and decide just to boot with openrc. This is what I am doing.

In fact, I am still happy to have systemd as an emergency boot system, but after I had severe data loss of squsahmount data with it (and it was not the fault of squsahmount), I am careful to avoid resquashing when booting with systemd.

On the other hand, if you are not using a special setup (like e.g. with mount --make-shared for some partitions), chances are good that you can use squashmount with systemd without any issues, provided you have linux-utils emerged with USE=systemd.

----------

## gringo

thanks !

 *Quote:*   

> Do you mean undoing squashmount or systemd?

 

sorry for not being clear enough : i meant squashmount.

i have just stopped squashmount and have now empty target directories, i guess something else has to be done to have the contents back ?

Just to be clear enough, one of the squashed dirs i have is /var/db, after stopping squashmount i end up with an empty /var/db directory.

TIA !

----------

## 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".

 *Quote:*   

> i have just stopped squashmount and have now empty target directories

 

If they are empty while squashmount+systemd are running, you have hit the mentioned systemd bug.

If they were correct while squashmount was running and you called squashmount stop, they are supposed to be empty, since the content of the directory is now in the squashed file. You can unsquash the file to get the content without mounting anything. However, in this case you do not have a reason to do so, since apparently squashmount+systemd then just works for you.

----------

## mv

You will find more information about the interaction of systemd+squashmount (and why "official" support has been dropped) in the next release of squashmount.

However, this release might take a while, since it probably only appear after linux-3.19 is more widely available (in particular, when >=hardened-sources-3.19 have appeared): The reason is that this release will also change the default compression method to "lz4" which is only available with linux-3.19 or newer.

(Of course, you can change this default, but it would not be sane to publish a release with a default which works for almost nobody).

----------

## gringo

 *Quote:*   

> f they are empty while squashmount+systemd are running, you have hit the mentioned systemd bug.

 

yes, thats what apparently happened.

i have just synced over yesterdays backups and lets see if i hit this again or not.

thanks for your time !

----------

## mv

 *gringo wrote:*   

>  *Quote:*   f they are empty while squashmount+systemd are running, you have hit the mentioned systemd bug. 
> 
> yes, thats what apparently happened.

 

The problem is: If squashmount "thinks" that they are mounted, but if they are are actually not mounted due to the systemd bug, and if the CHANGES directory is nonempty, then squashmount will just squash them and produce an empty squash file. If this has happened, your data is lost if you do not make a BACKUP (check the size of .sfs and/or of the BACKUP file).

Have you compiled util-linux with USE=systemd?

(So far, I have not been able to produce the systemd bug in this case with squashmount, although I could still produce a similar systemd bug with device-mapper).

----------

## gringo

 *Quote:*   

> The problem is: If squashmount "thinks" that they are mounted, but if they are are actually not mounted due to the systemd bug, and if the CHANGES directory is nonempty, then squashmount will just squash them and produce an empty squash file. If this has happened, your data is lost if you do not make a BACKUP (check the size of .sfs and/or of the BACKUP file). 

 

ugh, nasty one !

that is what happened to portage dir apparently ( backups are all 0 size) but not with the db dir backups, these are apparently fine.

i didnt use these backup files btw, i have my box backed up every day and just used those.

so far so good, will report back if i hit this again.

 *Quote:*   

> Have you compiled util-linux with USE=systemd?

 

yes, i have the gnome/systemd profile set which enables the systemd USE automatically.

```
sys-apps/util-linux-2.26  USE="cramfs ncurses nls pam suid systemd udev unicode -caps -fdformat -python (-selinux) -slang -static-libs {-test} -tty-helpers" ABI_X86="(64) -32 (-x32)" PYTHON_SINGLE_TARGET="python2_7 -python3_3 -python3_4" PYTHON_TARGETS="python2_7 -python3_3 -python3_4"
```

thanks for your time !

----------

## mv

It would be nice to know what is triggering the bug in your case. Do you have some special mount settings (like --make-shared for some partitions)?

You can try mounting manually. If you use the default paths (and use "overlay"), squashmount should essentially do:

```
modprobe loop

modprobe squashfs

mount -t squashfs -o loop,ro,noatime -- /usr/portage.mount/portage.sfs /usr/portage.mount/readonly

modprobe overlay

mount -t overlay -o noatime -o upperdir=/usr/portage.mount/changes -o lowerdir=/usr/portage.mount/readonly -o workdir=/usr/portage.mount/workdir -- overlay /usr/portage
```

In the "buggy" case, the mount actually does not happen, that is, the directory /isr/portage.mount/readonly or the directory /usr/portage still have the old content, and also the corresponding command

```
umount /usr/portage

umount /usr/portage.mount/readonly
```

 fails. (Of course, if your .sfs-file is empty, your directory will be empty also in the "success" case, but the unmount should not fail in the "success" case).

Why the above mount commands sometimes fail with systemd - I have no idea: They report success, the kernel sends a message that it mounted - but "mount" does not show that anything was mounted, and it just seems as if the commend was not sent. The problem is obviosly that systemd builds a (buggy) layer between the "mount" command and the kernel: Note that "systemctl" will also show that the corresponding ".mount"-units are started (which is of course a nonsense, since such units do not exist - this appears to be some systemd-internal hackery).

----------

## gringo

 *Quote:*   

> Do you have some special mount settings (like --make-shared for some partitions)?

 

nope, no fancy mount options here, setup file is fairly basic i think : 

```
#!/usr/bin/perl

@order = ( 'unionfs-fuse' );

push(@mounts, {

   TAG => 'db',

   DIR => '/var/db',

   FILE => '/var/db.sqfs',

   BACKUP => '/var/db.sqfs.bak',

   CHANGES => '/var/db.changes',

   READONLY => '/var/db.readonly',

   THRESHOLD => '30m',

   BLOCKSIZE => 65536

   }, {

   TAG => 'portage',

   DIR => '/var/repos/portage',

   FILE => '/var/repos/portage.sqfs',

   CHANGES => '/var/repos/portage.changes',

   READONLY => '/var/repos/portage.readonly',

   THRESHOLD => '40m'

   });
```

this hasnt been touched since first setup.

 *Quote:*   

> modprobe loop
> 
> modprobe squashfs
> 
> mount -t squashfs -o loop,ro,noatime -- /usr/portage.mount/portage.sfs /usr/portage.mount/readonlythis just happened today when i tried to update world.
> ...

 

the above worked without problems for both /var/repos/portage & /var/db.

im running now latest systemd ( just updated world a couple of minutes ago).

another problem is i didnt use portage at all for a couple of weeks and maybe this has been happening for a while already.

 *Quote:*   

> Why the above mount commands sometimes fail with systemd - I have no idea: They report success, the kernel sends a message that it mounted - but "mount" does not show that anything was mounted, and it just seems as if the commend was not sent. The problem is obviosly that systemd builds a (buggy) layer between the "mount" command and the kernel: Note that "systemctl" will also show that the corresponding ".mount"-units are started (which is of course a nonsense, since such units do not exist - this appears to be some systemd-internal hackery).

 

sorry but i have no idea either. Is there some way to tell systemd to make lots of noise when the mount units are called ?

thanks !

----------

## mv

 *gringo wrote:*   

> @order = ( 'unionfs-fuse' );

 

It might be a problem with unionfs-fuse. With unionfs-fuse, the second "mount" command should be instead:

```
unionfs -o cow -o allow_other -o use_ino -o nonempty -o noatime -o hide_meta_files /usr/portage.mount/changes=RW:/usr/portage.mount/readonly=RO /usr/portage
```

Maybe this is what causes the issues with systemd?

If yes, a "solution" to your problem is to change to "overlay", of course (which I would recommend anyway, already because of speed reasons).

 *Quote:*   

> Is there some way to tell systemd to make lots of noise when the mount units are called?

 

I am afraid not: They do not even appear in any log; only "systemctl" itself seems to know about them.

(In fact, actually systemd should not be called at all for "mount" - it is very strange that it knows about this mounting at all; somehow, linux-utils must invoke systemd somehow implicitly, or perhaps systemd catches mounts indirectly over kernel events and udev).

----------

## mv

Just as a link collection that squashmount is not the only program suffering from the systemd misconceptions: There is the device mapper issue and also another bug report for squashfs mounting with systemd (in which hacky workaroiunds are suggested, as I had expected; but as pointed out, squashmount will not add dirty hacks to workaround the bugs resulting from the systemd misconception).

----------

## costel78

This is completely silly. How can systemd developers take over mount/mtab etc ? What is the goal, the user benefit  ? 

And, it they, nevertheless, do that, can't they think at a such simple case as loop-mount ?

Yes, I really make, too, a lot of mistakes. I am an human. But very, very few conceptual ones. And I am just a person, not a whole team of developers.

I really hope that gnome-3.16 really deliver what they promised since 3.14 version: get rid of hard-dependency of systemd.

Until then, I hardmasked any version of systemd greater that 218. I don't want to quit using squashmount.

----------

## mv

 *costel78 wrote:*   

> How can systemd developers take over mount/mtab etc? What is the goal, the user benefit?

 

Their goal is to rule the world. This starts by pretending to be the operating system without which mount will not work: The whole purpose of sytemd is to be "system" daemon - the talking about an init-system was just a means to become the actual operating system.

The claimed user benefit is probably that handling of containers can work better if systemd knows about all mounts so that mounted partitions can be pushed (or intentionally excluded) from containers/chroots.

The practical user "benefit" is of course just breakage of the existing infrastructure, since in the long run it should be replaced by systemd infrastructure completley. We will perhaps soon see attempts to subsume squashmount into systemd in a poor way.

----------

## Massimo B.

I'm not on systemd but on sane OpenRC.

There I have often a read-only filesystem, so I need to remount it. What is the problem here?

```
>>> Installing (1 of 3) app-office/libreoffice-l10n-4.3.5.2::gentoo

 * One or more files installed to this package are set to be installed to

 * read-only filesystems. Please mount the following filesystems as read-

 * write and retry.

 * 

 *    /usr/lib64/libreoffice

 * 

 * Package 'app-office/libreoffice-l10n-4.3.5.2' NOT merged due to read-

 * only file systems. If necessary, refer to your elog messages for the

 * whole content of the above message.
```

Often I only see that after very long builds (libreoffice) and I need to restart emerge after the remount.

----------

## mv

 *Massimo B. wrote:*   

> There I have often a read-only filesystem, so I need to remount it.

 

I don't know: This never happened to me (and I do have libreoffice on a squashmounted partition). When this happens, which filesystem type does 

```
squashmount list
```

 show?

Please, also report which type you are using (overlay, overlayfs, aufs, unionfs-mount, ...) and whether the output  of the above command corresponds to the desired type.

----------

## Massimo B.

OK, so here I have that issue again:

```
# touch /usr/lib64/libreoffice/test

touch: cannot touch ‘/usr/lib64/libreoffice/test’: Read-only file system

# squashmount list

 * [adobe]:            overlay  (10m), unmodified

 * [firefox]:          bind

 * [icedtea6]:         overlay  (10m), unmodified

 * [icedtea7]:         overlay  (10m), unmodified

 * [layman]:           overlay  (10m), modified, but will not resquash

 * [libreoffice]:      bind

 * [local_portage]:    overlay  (10m), modified, but will not resquash

 * [vmware]:           overlay  (10m), unmodified

 * [lib-vmware-tools]: overlay  (50m), modified, but will not resquash

 * [texmf]:            overlay  (10m), unmodified

 * [texlive_local]:    overlay  (10m), unmodified

 * [portage]:          overlay (100m), unmodified

 * [ccache]:           overlay (250m), unmodified

 * [db]:               overlay  (40m), modified, but will not resquash
```

I'm using overlay (kernel-module), lzo compression.

squashmount remount does nothing, and squashmount remount -f fixes that issue, until it happens again.

Could this be caused by my hourly cron-job? I have that to reduce long system halt times when resquashing. I'm going to disable that:

```
#!/usr/bin/env bash

this_basename="${0##*/}"

this_dirname="${0%/*}"

if pgrep -f "emerge|eix" >/dev/null; then

    logger -t $this_basename "squashmount flush skipped due to running emerge."

else

    squashmount remount

    logger -t $this_basename "squashmount flush finished."

fi
```

----------

## mv

 *Massimo B. wrote:*   

> OK, so here I have that issue again:
> 
> ```
> # touch /usr/lib64/libreoffice/test
> 
> ...

 

So the information which squashmount has internally coincides with reality: When squashmount tried to (re-)mount firefox and libreoffice, for some reason the mounting of "overlay" (as well as of overlayfs, auf, unionfs-fuse, ... if configured) all failed, and as a last resort, squashmount felt back to "mount --bind" to provide the directory at least in a readonly-manner.

When and why this fails cannot be seen here: This should be visible in the output of the corresponding "squashmount start/mount/remount" where the mounting failed.

 *Quote:*   

> Could this be caused by my hourly cron-job?

 

This cron-job has a serious race: If you start emerge after the first grep (that is, while the cronjob ist compressing), all sort of bad things can happen. For instance, emerge might write data to portage while the compression job is running. I do not know how mksquashfs reacts when a file is removed/modified/added while it is compressing. But even if it is fine, it might happen that between umounting and new mounting some data is written, so that the new DIR is not empty during the mount. This cause overlay to bail out.

OTOH, I cannot imagine that this race occurs when you emerge libreoffice: It is hard to believe that recompression takes longer than emerging libreoffice.

Since you say that it is a cron-job: The output of "squashmount remount" should have been saved somewhere: Do you see some error messages?

 *Quote:*   

> I have that to reduce long system halt times when resquashing

 

It is probably safer to do this manually. Moreover, if you have >=linux-3.19, I would recommend to switch to lz4 (which will be default in the next squashmount release): This reduces the compression times dramatically (see compress.txt)

----------

## Petros

Hey there @mv. You have done such an excellent job with squashmount. Thank you, portage and eix are faster now  :Smile:  I have to admit though, I 've been using it for 3-4 days and I am not quite sure I have done things right.

For some reason I must run 

```
emerge -av @preserved-rebuild
```

 on my machine. But portage was complaining this :

```
emerge: there are no ebuilds to satisfy "net-im/ktp-desktop-applets:5"
```

 only when squashmount was up and running. If I stop it,  net-im/ktp-desktop-applets:5 is found with no problem.

I updated my overlays and eix cache (eix-update), I restarted squashmount (squashmount restart) and the problem still insists. It seems something is missing from the squashed trees and thus portage can't find net-im/ktp-desktop-applets:5 although it is out there.

My /etc/squashmount.pl

```
#!/usr/bin/perl (this is only for editors) 

# The tools which we have installed; if possible only the first in this list 

# is used, but the others are a fallback if that fails. 

@order = ('aufs', 'overlayfs', 'unionfs-fuse', 'unionfs', 'funionfs');

# Even if we define following is empty it is convenient to use 

# this local variable throughout, so that we can simply change it: 

my $defaults = {

   COMPRESSION => 'lz4',

   COMPOPT_LZ4 => '',

};

DIFF => 1;

RESQUASH_ON_START => 1;

push(@mounts, {

   TAG => 'portage',

   DIR => '/usr/portage',

   FILE => '/usr/portage.sqfs',

   CHANGES => '/usr/portage.changes',

   READONLY => '/usr/portage.readonly',

   #RESQUASH_ON_START => 1, 

   THRESHOLD => '0.1m' # resquash on umount if 40 megabytes changed 

#}, {

#               TAG => '.config',

#               DIR => '/home/petros/.config',

#               FILE => '/home/petros/.config.sqfs',

#               CHMOD => 0400, # squashfile readonly by user

#               CHOWN => [ (getpwnam('petros'))[2], # user and group of ...

#                       (getgrnam('petros'))[2] ],  # ... new squashfile's owner

#               KILL => 1, # normally remove data on every umount/remount

#               # Clean temporary directories, independent of defaults:

#               RM_CHANGES => 1, RM_WORKDIR => 1, RM_READONLY => 1,

                # If you want to cancel this KILL temporarily

                # (e.g. to make modifications on guest-skeleton.sqsf)

                # use something like "squashmount --nokill set"

                # In such a case, we must no postpone resquashing

                # even if $resquash_on_start should be true, becuse

                # CHANGES is a temporary directory:

#               RESQUASH_ON_START => '' 

}, {

   TAG => 'db',

   DIR => '/var/db',

   FILE => '/var/db.sqfs',

   CHANGES => '/var/db.changes',

   READONLY => '/var/db.readonly',

   THRESHOLD => '0.1m' # resquash on umount if 40 megabytes changed 

}, {

   TAG => 'layman',

   DIR => '/var/lib/layman',

   FILE => '/var/lib/layman.sqfs',

   CHANGES => '/var/lib/layman.changes',

   READONLY => '/var/lib/layman.readonly',

   THRESHOLD => '0.1m'

}, {

   TAG => 'eix',

   DIR => '/var/cache/eix/',

   FILE => '/var/cache/eix.sqfs',

   CHANGES => '/var/cache/eix.changes',

   READONLY => '/var/cache/eix.readonly',

   THRESHOLD => '0.1m'

});

@umount = ('-i');
```

I am afraid I made mistakes when configuring. Thanks in advanced for any recommandation.  :Smile: 

----------

## mv

I do not really have an idea what is the problem in your case. If it is only one or two ebuilds, I can hardly imaigne that it is a problem of squashmount/aufs.

I can only offer some shots in the dark.

 *Petros wrote:*   

> It seems something is missing from the squashed trees and thus portage can't find net-im/ktp-desktop-applets:5 although it is out there.

 

It is not in the main tree: The main tree contains only net-im/ktp-desktop-applets:4. Maybe it was there and was removed?

You do not descraibe how you manage to "stop" squashmount: If you just call "squashmount stop" the portage tree should be empty; or maybe you see an old tree then which (still?) contains  net-im/ktp-desktop-applets:5?

Or maybe you have it from some overlay. In this case: Are other packages from that overlay visible? Is the ebuild actually in the overlay? (Maybe it has been msked e.g.). If portage gets confused it migh help to remove /var/cache/edb/dep

Concerning your config: I realize that you do not have set WORKDIR. This is OK if you use aufs, but this is not a good idea with overlayfs; better keep WORKDIR in a permanent directory. If you use overlayfs, this might perhaps be a reason for your trouble.

MInor remarks:

```
my $defaults = {

   COMPRESSION => 'lz4',

   COMPOPT_LZ4 => '',

};
```

Since you do not refer to this variable later, it is pointless to set it.

```
DIFF => 1;

RESQUASH_ON_START => 1;
```

I am surprised that perl did not report a warning for these lines: They have completely no effect.

 *Quote:*   

>    TAG => 'eix',
> 
>    DIR => '/var/cache/eix/',
> 
>    FILE => '/var/cache/eix.sqfs'

 

Squashing this directory does not have much advantage: I would be surprised if you save space or time.

```
@umount = ('-i');
```

Do you have a reason to set this?

The last line in your config-file should be 

```
1;
```

 (although your above last line should work too, by accident).

----------

## Petros

Thank you for answering my -rather- bad description of what happened.

net-im/ktp-desktop-applets:5 is indeed on ::kde overlay. Whenever I run 

```
squashmount start
```

 portage can no longer find the ebuild. As soon as I run 

```
squashmount stop
```

 the problem disappears. Other packages from this overlay are visible. It is not masked; besides that portage finds it just fine when I run 

```
squashmount stop
```

I noticed and measured eix-update to be faster tha way. Before squashing the directory I measured 

```
time eix-update
```

 to be -> 1' 10". And after -> 0' 20". I use almost 80 overlays. Do you think something else happened?  

For the record I am running linux-3.19.2-aufs, sys-fs/aufs-util-3.19_p20150323.

Thanks  :Smile: 

----------

## Petros

After updating all overlays 

```
layman -S
```

 and deleting /var/lib/layman.sqfs (while not mounted), net-im/ktp-desktop-applets-9999:5::kde is visible again. It is as it wasn't syncing properly or for some reason the ebuild wasn't present/visible in layman.sqfs file. I don't know what to conclude, maybe my config file is bad or something is missing. 

Threshold is all about when the .sqfs will sync with the HDD, correct?

----------

## mv

 *Petros wrote:*   

> or for some reason the ebuild wasn't present/visible in layman.sqfs file.

 

One could have checked this manually, but I guess that now it is too late...

 *Quote:*   

> Threshold is all about when the .sqfs will sync with the HDD, correct?

 

To be precise, it is about when a "stop/umount" or "restart/remount" will re-squash the directory (and then clean CHANGES and WORKDIR).

----------

## Petros

Oh I see  :Wink:  Thank you.

----------

## Petros

I am back and I have (somewhat) the same problem.

I reinstalled Gentoo because of an accidental deletion of /var/db directory. Eveything is good so far except this:

When I first run squashmount I got informed tha {portage,db,layman,exi}.sqfs didn't exist and where created at that moment. When I unmounted them (squashmount stop) I realised that my directories where kind of missing.

My /var/lib/layman was empty. As soos as I mounted them back (start), everything was back to normal. Also eix various_packages gave different results. Emerge didn't work because it could not find /var/lib/layman/make.conf and as soon as I run squashmount start portage was working.

The most crazy of them all is that app-shells/bash was (un)installed, based on whether squasmount was running. I think the last one has to do with /var/db/pkg, the same directory that is rensposible (actually I am) for reinstalling Gentoo.

Aparently the directories aren't syncing. What the problem could be? My /etc/squashmount.pl :

```
#!/usr/bin/perl (this is only for editors)

# The tools which we have installed; if possible only the first in this list

# is used, but the others are a fallback if that fails.

@order = ('aufs', 'overlayfs', 'unionfs-fuse', 'unionfs', 'funionfs');

# Even if we define following is empty it is convenient to use

# this local variable throughout, so that we can simply change it:

my $defaults = {

   COMPRESSION => 'lz4',

   COMPOPT_LZ4 => '',

};

push(@mounts, {

   TAG => 'portage',

   DIR => '/usr/portage',

   FILE => '/usr/portage.sqfs',

   CHANGES => '/usr/portage.changes',

   READONLY => '/usr/portage.readonly',

   #BACKUP => '/usr/portage.bak',

   #RESQUASH_ON_START => 1,

   THRESHOLD => '1m' # resquash on umount if 40 megabytes changed

#}, {

#               TAG => '.config',

#               DIR => '/home/petros/.config',

#               FILE => '/home/petros/.config.sqfs',

#               CHMOD => 0400, # squashfile readonly by user

#               CHOWN => [ (getpwnam('petros'))[2], # user and group of ...

#                       (getgrnam('petros'))[2] ],  # ... new squashfile's owner

#               KILL => 1, # normally remove data on every umount/remount

#               # Clean temporary directories, independent of defaults:

#               RM_CHANGES => 1, RM_WORKDIR => 1, RM_READONLY => 1,

                # If you want to cancel this KILL temporarily

                # (e.g. to make modifications on guest-skeleton.sqsf)

                # use something like "squashmount --nokill set"

                # In such a case, we must no postpone resquashing

                # even if $resquash_on_start should be true, becuse

                # CHANGES is a temporary directory:

#               RESQUASH_ON_START => ''

}, {

   TAG => 'db',

   DIR => '/var/db',

   FILE => '/var/db.sqfs',

   CHANGES => '/var/db.changes',

   READONLY => '/var/db.readonly',

   #BACKUP => '/var/db.bak',

   THRESHOLD => '1m' # resquash on umount if 40 megabytes changed

}, {

   TAG => 'layman',

   DIR => '/var/lib/layman',

   FILE => '/var/lib/layman.sqfs',

   CHANGES => '/var/lib/layman.changes',

   READONLY => '/var/lib/layman.readonly',

   #BACKUP => '/var/lib/layman.bak',

   THRESHOLD => '1m'

}, {

   TAG => 'eix',

   DIR => '/var/cache/eix/',

   FILE => '/var/cache/eix.sqfs',

   CHANGES => '/var/cache/eix.changes',

   READONLY => '/var/cache/eix.readonly',

   #BACKUP => '/var/cache/eix.bak',

   THRESHOLD => '1m'

});

@umount;

1;
```

----------

## mv

 *Petros wrote:*   

> When I unmounted them (squashmount stop) I realised that my directories where kind of missing.

 

This is how it should be: The data is only stored in the *.sfs file - this is the whole point of squashmount. When nothing is mounted, you cannot access the data, of course.

Normally, you should never call "squashmount stop" or "squashmount umount" in a running system (unless you know what you are doing):

The "normal" mode of operation is to run "squashmount start" during booting and "squashmount stop" during shutdown (normally, both happens automatically): This way, "normally" the data is visible and can be changed when running the system, and during shutdown the data is resquashed (unless there are not enough changes to reach the threshold if you configured some).

Calling "squashmount" manually is needed only in those very rare situations when you want to deviate from this "normal" mode (e.g. because you want to resquash earlier than at the next shutdown for some reason, or of you want to skip recompression because you need a quick shutdown, or something similar). And whenever you do this, you should be sure that nothing accesses the corresponding directories until squashmount is succesfully started again.

 *Quote:*   

> The most crazy of them all is that app-shells/bash was (un)installed

 

This is to be expected: If you umounted/stopped the mountpoint with /var/db, this directory of installed packages is empty, that is, if you run portage/eix afterwards (which you should not be doing) then portage/eix will not find any installed packages there.

----------

## Petros

I though my data were present to both direcoties/sqfs files when it squashmount is running. I was wrong but I can now use squasmount in a more proper way.

So if I (for any reason) want to stop squasmount or uninstall it, all I have to do is to unsquash my .sqfs files and then proceed in order not to lose my data, especially those in /var/db. Now I can understand why deleting /var/db.{sqfs,changes,etc) made my system useless.

Correct me if I am wrong or missing something, not only for my benefit but also for future reference to someone else.

Thank you for your time  :Smile: 

----------

## mv

 *Petros wrote:*   

> So if I (for any reason) want to stop squasmount or uninstall it, all I have to do is to unsquash my .sqfs files

 

Yes.

 *Quote:*   

> why deleting /var/db.{sqfs,changes,etc) made my system useless.

 

Removing /var/db.sqfs means that you have lost your data. (There might be a slight chance to recover the data when you removed it by mistake while the file is mounted, because the linux kernel will delay that actual removal of the data until the file is no longer accessed - but in the moment when the file is no longer mounted, the data is lost). This is why squashmount has an option to keep a backup of that file: Especially for sensitive data like /var/db this is recommended; in an emergency case, you have at least still the previous version...

----------

## Petros

 *Quote:*   

> Removing /var/db.sqfs means that you have lost your data. (There might be a slight chance to recover the data when you removed it by mistake while the file is mounted, because the linux kernel will delay that actual removal of the data until the file is no longer accessed - but in the moment when the file is no longer mounted, the data is lost). This is why squashmount has an option to keep a backup of that file: Especially for sensitive data like /var/db this is recommended; in an emergency case, you have at least still the previous version...

 

Well, that make sense after all. How fool of me to delete those dirs.

----------

## Massimo B.

I have squashed /opt/lib/vmware-tools. But almost every reboot it must be resquashed. Checking what has changed like

```
find /opt/lib/vmware-tools -mtime 7
```

shows nothing. What is the cause for the many re-squashing?

----------

## mv

Check the CHANGES directory

----------

## Massimo B.

I applied squashmount with lzo to some 13GB git repository, reducing space to ~25% and speeding up rebase from >3min to ~1,3min...

Now the question, resquashing takes /tmp on root fs which has not enough space. How can I change the tmp to the location where the squashfs itself is stored? I can't find if that is a mksquashfs option or squashmount related.

----------

## mv

 *Massimo B. wrote:*   

> How can I change the tmp to the location where the squashfs itself is stored?

 

squashmount --man: TEMPDIR => '/path-to-a-tmpdir-on-partition-with-squashfile'

Note that the change takes effect only after you stop'ed squashmount.

----------

## Massimo B.

 *mv wrote:*   

> squashmount --man: TEMPDIR => '/path-to-a-tmpdir-on-partition-with-squashfile'

 Thanks, and sorry I did not know --man, only --help and the /usr/share/doc/squashmount-*/README. Why not installing a usual man-page via ebuild?

----------

## mv

 *Massimo B. wrote:*   

> Why not installing a usual man-page via ebuild?

 

The perl-ish way is to have the manpage built into the program, because perl has its own nroff variant "pod" (man perlpod).

 *squashmount --help wrote:*   

> Usage:
> 
>     squashmount [options] *command* [*mask1* *mask2* ...]
> 
>             Where *command* is one of mount, umount, remount, set, reset,
> ...

 

Of course 

```
squashmount man
```

 works, as well...

----------

## schorsch_76

Today i tried to setup my portage to an squashfsmounted filesystem.

```

#!/usr/bin/perl (this is only for editors)

# The tools which we have installed; if possible only the first in this list

# is used, but the others are a fallback if that fails.

@order = ('overlayfs');

# Even if we define following is empty it is convenient to use

# this local variable throughout, so that we can simply change it:

DIFF => 1;

RESQUASH_ON_START => 1;

push(@mounts, {

   TAG => 'portage',

   DIR => '/usr/portage',

   FILE => '/usr/portage.sqfs',

   CHANGES => '/usr/portage.changes',

   READONLY => '/usr/portage.readonly',

   THRESHOLD => '40m', # resquash on umount if 40 megabytes changed

   COMPRESSION => 'lz4'   

});

@umount = ('-i');

```

I started squashmount, it packaged /usr/portage and mounted it but i get the error

```
 * [portage]: mounting...

 * [portage]: error:   fallback to mount --bind

```

I got in my kernel

```

zcat /proc/config.gz | grep OVERLAY

CONFIG_OVERLAY_FS=m

zcat /proc/config.gz | grep SQUASH

CONFIG_SQUASHFS=y

CONFIG_SQUASHFS_FILE_CACHE=y

# CONFIG_SQUASHFS_FILE_DIRECT is not set

CONFIG_SQUASHFS_DECOMP_SINGLE=y

# CONFIG_SQUASHFS_DECOMP_MULTI is not set

# CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU is not set

CONFIG_SQUASHFS_XATTR=y

CONFIG_SQUASHFS_ZLIB=y

CONFIG_SQUASHFS_LZ4=y

CONFIG_SQUASHFS_LZO=y

CONFIG_SQUASHFS_XZ=y

CONFIG_SQUASHFS_4K_DEVBLK_SIZE=y

CONFIG_SQUASHFS_EMBEDDED=y

CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3

```

mount --bind works in other use cases too, so .. where micht be the problem?

mount tells me ...

```
 mount | column -t

proc                        on  /proc                     type  proc      (rw,nosuid,nodev,noexec,relatime)

udev                        on  /dev                      type  devtmpfs  (rw,nosuid,relatime,size=10240k,nr_inodes=2048587,mode=755)

devpts                      on  /dev/pts                  type  devpts    (rw,relatime,gid=5,mode=620)

sysfs                       on  /sys                      type  sysfs     (rw,nosuid,nodev,noexec,relatime)

/dev/mapper/desktop-gentoo  on  /                         type  ext4      (rw,noatime,data=ordered)

tmpfs                       on  /run                      type  tmpfs     (rw,nodev,relatime,size=1639252k,mode=755)

mqueue                      on  /dev/mqueue               type  mqueue    (rw,nosuid,nodev,noexec,relatime)

shm                         on  /dev/shm                  type  tmpfs     (rw,nosuid,nodev,noexec,relatime)

configfs                    on  /sys/kernel/config        type  configfs  (rw,nosuid,nodev,noexec,relatime)

cgroup_root                 on  /sys/fs/cgroup            type  tmpfs     (rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755)

fusectl                     on  /sys/fs/fuse/connections  type  fusectl   (rw,nosuid,nodev,noexec,relatime)

openrc                      on  /sys/fs/cgroup/openrc     type  cgroup    (rw,nosuid,nodev,noexec,relatime,release_agent=/lib64/rc/sh/cgroup-release-agent.sh,name=openrc)

cpuset                      on  /sys/fs/cgroup/cpuset     type  cgroup    (rw,nosuid,nodev,noexec,relatime,cpuset)

cpuacct                     on  /sys/fs/cgroup/cpuacct    type  cgroup    (rw,nosuid,nodev,noexec,relatime,cpuacct)

/dev/sda1                   on  /boot                     type  ext2      (rw,noatime)

/dev/mapper/desktop-home    on  /home                     type  ext4      (rw)

none                        on  /var/tmp/portage          type  tmpfs     (rw,size=12G)

/usr/portage.sqfs           on  /usr/portage.readonly     type  squashfs  (ro,noatime)

/usr/portage.readonly       on  /usr/portage              type  none      (ro,bind)

```

I am on openrc  :Wink: 

EDIT: Problem existed between keyboard and chair ..... overlay ... overlayfs *DOH*

----------

## Massimo B.

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
> ...

 

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?

BTW looking for a low bandwidth consuming sync-type I ended with 

```
sync-type = git

sync-uri = git://github.com/gentoo/gentoo-portage-rsync-mirror
```

..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.

----------

## mv

 *Massimo B. wrote:*   

> 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.

----------

## Massimo B.

 *mv wrote:*   

> 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:

```
this_basename="${0##*/}"

this_dirname="${0%/*}"

if pgrep -f "emerge|eix" >/dev/null; then

    logger -t $this_basename "squashmount flush skipped due to running emerge."

else

    squashmount remount

    logger -t $this_basename "squashmount flush finished."

fi

```

 *Quote:*   

>  *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.

 

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  :Smile: 

----------

## mv

 *Massimo B. wrote:*   

> 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.

 

To shut down quickly, you can use

```
squashmount -n set
```

(provided that CHANGES is not cleaned during shutdown, of course).

Or setting a reasonable THRESHOLD value can help, too...

Or if the time during booting is not important, there is also RESQUASH_ON_START available.

----------

## Petros

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

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

----------

## schorsch_76

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

```

squashmount remount -s src

```

```

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 ....   :Embarassed: 

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)  :Wink: 

EDIT: A very very nice and neat tool you wrote there!   :Cool: 

----------

## mv

 *schorsch_76 wrote:*   

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

 

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).

----------

## mv

 *Petros wrote:*   

> 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.

----------

## Petros

Thank you very much. Indeed, squashing the directory that glibc resides in, is going to render this lib inaccessible. 

Maybe a ramdisk or something like that could be a more elegant solution.

----------

## schorsch_76

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...

I think about it, for my amdgeodelx system....

[1] http://www.tldp.org/HOWTO/html_single/SquashFS-HOWTO/

----------

## mv

 *schorsch_76 wrote:*   

> 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.

----------

## mv

 *schorsch_76 wrote:*   

> 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.

----------

## Massimo B.

Interesting comment about why libreoffice can fail with squashmount: 536558#c7

----------

## mv

 *Massimo B. wrote:*   

> Interesting comment about why libreoffice can fail with squashmount: 536558#c7

 

Interesting. However, I cannot reproduce it. For me libreoffice just always worked with squashmount.

----------

## Massimo B.

Occasionally I can't sync the mv overlay with eix-sync anymore:

```
>>> Syncing repository 'mv' into '/var/lib/layman/mv'...

>>> Starting layman sync for mv...

 * Running Git... # ( cd /var/lib/layman/mv  && /usr/bin/git pull --depth=1 )

U   games-rpg/m5figur-mv/ChangeLog

U   games-rpg/m5figur-mv/Manifest

A   games-rpg/m5figur-mv/m5figur-mv-2.4.ebuild

Pull is not possible because you have unmerged files.

Please, fix them up in the work tree, and then use 'git add/rm <file>'

as appropriate to mark resolution and make a commit.

 * Failure result returned from Git

 * 

 * Errors:

 * ------

 * Failed to sync overlay "mv".

 * Error was: Syncing overlay "mv" returned status 1!

 * db.sync()
```

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

```
git reset --hard origin/master
```

, but I need to do that occasionally, it is not an issue with other overlays.

----------

## mv

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.)

----------

## mv

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.

----------

## Massimo B.

There it is again:

```
From git://anongit.gentoo.org/user/mv

 + 3327936...a7f519f master     -> origin/master  (forced update)

Auto-merging www-plugins/noscript/Manifest

CONFLICT (add/add): Merge conflict in www-plugins/noscript/Manifest

Auto-merging www-plugins/noscript/ChangeLog

CONFLICT (add/add): Merge conflict in www-plugins/noscript/ChangeLog

Auto-merging sys-apps/schedule/Manifest

CONFLICT (add/add): Merge conflict in sys-apps/schedule/Manifest

Auto-merging sys-apps/schedule/ChangeLog

CONFLICT (add/add): Merge conflict in sys-apps/schedule/ChangeLog

Auto-merging sys-apps/cpi/Manifest

CONFLICT (add/add): Merge conflict in sys-apps/cpi/Manifest

Auto-merging sys-apps/cpi/ChangeLog

CONFLICT (add/add): Merge conflict in sys-apps/cpi/ChangeLog

Auto-merging media-video/video-mv/Manifest

CONFLICT (add/add): Merge conflict in media-video/video-mv/Manifest

Auto-merging media-video/video-mv/ChangeLog

CONFLICT (add/add): Merge conflict in media-video/video-mv/ChangeLog

Automatic merge failed; fix conflicts and then commit the result.

 * Failure result returned from Git
```

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?

----------

## mv

 *Massimo B. wrote:*   

> So this was a rebase again?

 

Might be; I don't remember.

 *Quote:*   

>  On the mv overlay it happens quite often

 

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...)

----------

## Petros

I decided to compress my ~/.config directory with squashmount, but I have some trouble.

My Plasma refuses to boot with a recently (re)squashed .config dir, unless I change the owner of the directory.

```
sudo chown petros:petros ~/.config && sudo chown petros:petros ~/.config*
```

But squashmount.pl has a field in which permmisions are set for my user.

```
added_hash($defaults, { 

               TAG => '.config', 

               DIR => '/home/petros/.config', 

               FILE => '/home/petros/.config.sqfs', 

               CHANGES => '/home/petros/.config.changes',

               READONLY => '/home/petros/.config.readonly',

               BACKUP => '/home/petros/.config.backup',

               CHMOD => 0770, # squashfile readonly by user 

               CHOWN => [ (getpwnam('petros'))[2], # user and group of ... 

                       (getgrnam('petros'))[2] ],  # ... new squashfile's owner 

                THRESHOLD => '1m'

#               KILL => 1, # normally remove data on every umount/remount 

#               # Clean temporary directories, independent of defaults: 

#               RM_CHANGES => 1, RM_WORKDIR => 1, RM_READONLY => 1, 

                # If you want to cancel this KILL temporarily 

                # (e.g. to make modifications on guest-skeleton.sqsf) 

                # use something like "squashmount --nokill set" 

                # In such a case, we must no postpone resquashing 

                # even if $resquash_on_start should be true, becuse 

                # CHANGES is a temporary directory: 

#               RESQUASH_ON_START => '1' 

}),
```

I tried in the first place with the default setting (after removing #) without any success. I searched for someone else's post but didn't find anything.

----------

## cal22cal

 *Petros wrote:*   

> I decided to compress my ~/.config directory with squashmount, but I have some trouble.
> 
> 

 

Got the same problem, though.

sys-fs/squashmount-12.1.1 using kernel  4.1.6-gentoo with overlay

Have to manually chown me:me /home/me/.config.changes

Then got the write right.

----------

## mv

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.

----------

## Petros

 *mv wrote:*   

> 
> 
> 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.

 

That solved the problem , at least for a first try / KDE boot. Thank you for your effort, you have done an excellent job  :Smile: 

----------

## Petros

Maybe my question is irrelevant to squashmount, but how can I start an openrc service (including squashmount) if I am repairing my installation with a liveDVD/chroot?

The only way to emerge a package is to append --nodeps in order to avoid circular dependencies due to innaccesible pkg database.

----------

## mv

 *Petros wrote:*   

> Maybe my question is irrelevant to squashmount, but how can I start an openrc service (including squashmount) if I am repairing my installation with a liveDVD/chroot?

 

Maybe somebody corrects me, but I would say that there is no proper way to do that; copy your service to the livecd (if it supports openrc; e.g. sysrescuecd does) and start it from there.

This problem was one of the reasons why squashmount was rewritten without relying on any init system: In fact, the predecessor of squashmount (squash_dir) had introduced some special command ("START" with capital latters) which were a dirty workaround for that problem, but using just a separate command which is independent of any init-system is much cleaner, of course.

 *Quote:*   

> The only way to emerge a package is to append --nodeps in order to avoid circular dependencies due to innaccesible pkg database.

 

Do you mean, because /var/db is squashmount-compressed? It should be possible to call "squashmount mount" in a chroot; the chroot is not necessary if you modify your config-file correspondingly (or create symlinks) for the directories/files to be mounted; the --config option to specify the config-file might be handy in such a situation.

If everything fails, you can still "unsquashfs" your /var/db.mount/db.sfs

----------

## Petros

 *mv wrote:*   

> 
> 
> Do you mean, because /var/db is squashmount-compressed? It should be possible to call "squashmount mount" in a chroot; the chroot is not necessary if you modify your config-file correspondingly (or create symlinks) for the directories/files to be mounted; the --config option to specify the config-file might be handy in such a situation.
> 
> If everything fails, you can still "unsquashfs" your /var/db.mount/db.sfs

 

Yes, you are right. I suppose decompressing the .sfs files should apply for portage as well; not only db. After all, when gentoo is back and running, squashmount will re-compress these directoriesif .sfs files are missing.

EDIT. FTR I was refering to Gentoo LiveDVD, so yes it supports openrc.

----------

## Massimo B.

Hi, currently I get these error from squashmount:

```
$ squashmount remount

 * [layman]:           error:   umount skipped: dir in use: /var/lib/layman.mount/readonly

                                (this test can be skipped with --lsof=0)

 * [local_portage]:    remounting appears unnecessary

 * [portage]:          remounting appears unnecessary

 * [db]:               error:   umount skipped: dir in use: /var/db.mount/readonly

                                (this test can be skipped with --lsof=0)
```

I usually need the remount for manual re-squashing.

----------

## mv

I am also confused why lsof sometimes declares files from READONLY in use, although it is possible to umount that directory. This seems to be a bug somewhere (lsof, kernel, or the overlay module).

As the output says: You can use the option --lsof=0 to skip the check. You can make this the default by setting $lsof = 0 in the configuration, although I do not think that this would be a good idea.

----------

## Petros

 *Massimo B. wrote:*   

> Hi, currently I get these error from squashmount:
> 
> ```
> $ squashmount remount
> 
> ...

 

For the record, what kernel and squashmount version, do you use?

----------

## Massimo B.

 *Petros wrote:*   

> For the record, what kernel and squashmount version, do you use?

 [I] sys-fs/squashmount [1] (12.2.0@28.09.2015)

sys-kernel/ck-sources-4.0.7

----------

## Petros

 *Massimo B. wrote:*   

> [I] sys-fs/squashmount [1] (12.2.0@28.09.2015)
> 
> sys-kernel/ck-sources-4.0.7

 

Do you use an aufs patch or something? Or you don't use aufs at all in your squashmount configuration?

I am using aufs-sources and aufs and everything is normal.

----------

## Massimo B.

Right, on that system I use unionfs-fuse. On some other system with overlayfs in the kernel, I don't have that issue.

----------

## Petros

 *Massimo B. wrote:*   

> Right, on that system I use unionfs-fuse. On some other system with overlayfs in the kernel, I don't have that issue.

 

The other system you are refering to, has the same kernel - version, but only differs to unionfs?

Maybe the problem is unionfs or kernel specific. That's why I am asking you.

Did any kernel upgrade change the squashmount's behaviour?

----------

## mv

 *Petros wrote:*   

> Maybe the problem is unionfs or kernel specific.

 

The issue can also occur with overlay(fs). In my case, sometimes some font-files from /usr/share/texmf-dist.mount/readonly/ are reported by lsof, but it is too seldom to do any useful testing. It is (if it occurs) always the same two files - I suppose that the corresponding files in /usr/share/texmf-dist/ are used by the X server or some pdf/ps/...-viewer in some circumstances. However, the report is "false" in the sense that the directory can be umounted. It is also strange that only the files in .../readonly/ are supported and not those from /usr/share/texmf-dist/, but this may be a "feature" of overlay.

Edit: Maybe it is necessary to call "lsof" with some options? Currently, squashmount essentially just calls

```
lsof -- /usr/share/texmf-dist.mount/readonly
```

(discarding any output) and tests the exit status...

----------

## Petros

Hey I was wondering what if we could mount some of the directories we compress on to the RAM (/tmp directory).

http://skolima.blogspot.gr/2013/05/squashfs-portage-tree-saving-time-and.html

This guy over here manages to compress (squashfs) his portage, and mount it on RAM. But he doesn't make use any of aufs hacks to redirect the changes. He uses some bash and rsync in order to recompress the changes.

I think it would be a killer feature to combine your work and aufs, with the ability to mount portage/db on RAM. Maybe it coulb be like an option, not a necessity.

What do you think about this?

----------

## mv

 *Petros wrote:*   

> But he doesn't make use any of aufs hacks to redirect the changes.

 

Which means he actually cannot change it: He has to unpack the whole archive in disk, change the unpacked version, and repack the whole thing. It means a horrible waste of disk/memory space (at least temporary), and he looses all the advantages of having a writable directory. For instance, for things like /usr/share/texmf-dist or /var/db such an approach is not possible at all since these directories must be writable.

Such a thing makes sense only for PORTDIR, and for this there is the much better approach of mgorny of distributing binary diffs to the squashfile with the gentoo repository.

squashmount is ready to support that feature - everything it needs is implemented, and it was already tested with the implementation in portage - until some developers broke it: Some bugs were reported, mgorny complained about the breakage, and as a result mgorny (but actually the users) were "punished" by removing the implementation.

Bug the developers to return that feature!

 *Quote:*   

> with the ability to mount portage/db on RAM

 

I do not undesrtand what you mean. If you have enough ram to waste, you can of course use a ramdisk for the CHANGES directory if you want, which means that except for the squashfile itself everything will be in RAM.

----------

## Petros

What I mean with the last quote is that it could be nice if portage was on some kind of tmpfs. For example many gentoo system (with lot's of RAM) tend to mount /tmp directory as tmpfs and even redirect their TMPDIR over there, in order to compile on RAM. Anyway that's irrelevant, but I was wondering what if PORTDIR was copied/moved/you named it on /tmp and RAM? Dependencies calculation is going to be even faster?

Ayway instead of having two (I think) branches of each directory on the disk, one coulde be on tmpfs. For example when portage.sqfs is mounted and portage become visibleand accessible, the last could exist (somehow) on RAM and not on the disk. That is what I had on mind. But I guess your comment on the ramdisk, is the answer. Besides portage's size is not to be taken withouth caution.

About the binary diffs I will give it shot with a bug report.

Your patience is really appreciated. Thank you.

----------

## mv

 *Petros wrote:*   

> What I mean with the last quote is that it could be nice if portage was on some kind of tmpfs

 

If your CHANGES directory is empty, this won't help concerning speed, because also squashfs will be cached, and reading the metadata from the squashfile once costs only negligible time (since the metadata directory is kept together). If CHANGES is non-empty, you have presumably just synced so that this directory is cached, too.

Only if you kept the old CHANGES for a long time (e.g. on harddisk and rebooted in the meanwhile) you will experience a slowdown; that's why you should put a THRESHOLD to force resquashing after a certain minimal amount of entries of CHANGES. If you keep your system running for a long time without rebooting (so that squashmount had no change to resquash "automatically", and the time is so long that the cache for CHANGES becomes filled with other data meanwhile), I would recommend to call 

```
squashmount remount
```

 after a while ('though not in a cron job to avoid problems with surprisingly umounted directories).

----------

## Petros

The THRESHOLD value is quite low; just 1MB, so none of the problems you describe occur. Also I reboot at least once per 24h so....

Thanks   :Smile: 

----------

## Massimo B.

 *mv wrote:*   

> 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.)

 -> Bug #563464: Layman fails to reset and pull

----------

## mv

 *Massimo B. wrote:*   

> Bug #563464: Layman fails to reset and pull

 

Maybe this should have been announced here, but a few days ago the mv overlay received a "dramatic" restructuring: In order to allow for

```
egencache --repo=mv --update-changelogs
```

commits must not be coupled (which was previously done in the mv overlay whenever possible to save storage and traffic).

To solve this problem either the history had to be rewritten (which is rather error-prune and a lot of manual work or very tricky scripting) or removed.

To do the latter without actual data loss, a new "historical" branch with the previous history was created, and a new master branch started from scratch.

I am not that an expert in git, but I do not know a reliable way to fetch such dramatic changes except than by removing the previous copy and cloning again; I do not think that "reset --hard" would have been sufficient this time.

----------

## Massimo B.

If I get this right, you mean, after these changes on the repo the git reset --hard origin/master should have failed as well? It did not, I'm currently fine and fixed it as usual by the reset.

```
>>> Syncing repository 'mv' into '/var/lib/layman/mv'...

>>> Starting layman sync for mv...

 * Running Git... # ( cd /var/lib/layman/mv  && /usr/bin/git pull --depth=1 )

remote: Total 0 (delta 0), reused 0 (delta 0)

Already up-to-date.
```

----------

## Massimo B.

 *Massimo B. wrote:*   

> Bug #563464: Layman fails to reset and pull

 Concerning this issue I'm quite sure that my squashmount setup is responsible for the failing syncs, as nobody else encounters this errors. I'm using kernel overlay fs and lzo. The mv overlay needs the reset nearly every time now, and the kde overlay is failing completely with lot of ebuilds:

```
# emerge -auNDtv world --keep-going 

--- Invalid atom in /var/lib/layman/kde/profiles/package.mask/kde-apps-15.08.3: <<<<<<< HEAD

--- Invalid atom in /var/lib/layman/kde/profiles/package.mask/kde-apps-15.08.3: =======

--- Invalid atom in /var/lib/layman/kde/profiles/package.mask/kde-apps-15.08.3: >>>>>>> 0fda00f147613e49cba113025d083fcf2ca17fb9

These are the packages that would be merged, in reverse order:

Calculating dependencies |/var/lib/layman/mv/app-shells/runtitle/runtitle-2.7.ebuild: line 5: syntax error near unexpected token `<<<'

/var/lib/layman/mv/app-shells/runtitle/runtitle-2.7.ebuild: line 5: `<<<<<<< HEAD'

 * ERROR: app-shells/runtitle-2.7::mv failed (depend phase):

 *   error sourcing ebuild

 * 

 * Call stack:

 *   ebuild.sh, line 624:  Called die

 * The specific snippet of code:

 *            source "$EBUILD" || die "error sourcing ebuild"

 * 

 * If you need support, post the output of `emerge --info '=app-shells/runtitle-2.7::mv'`,

 * the complete build log and the output of `emerge -pqv '=app-shells/runtitle-2.7::mv'`.

 * Working directory: '/usr/lib64/python2.7/site-packages'

 * S: '/var/tmp/portage/app-shells/runtitle-2.7/work/runtitle-2.7'

 \/var/lib/layman/mv/sys-apps/less/less-481.ebuild: line 5: syntax error near unexpected token `<<<'

/var/lib/layman/mv/sys-apps/less/less-481.ebuild: line 5: `<<<<<<< HEAD'

 * ERROR: sys-apps/less-481::mv failed (depend phase):

 *   error sourcing ebuild
```

.. and lot more

```
# cd /var/lib/layman/mv

# git pull

error: Pull is not possible because you have unmerged files.

hint: Fix them up in the work tree, and then use 'git add/rm <file>'

hint: as appropriate to mark resolution and make a commit.

fatal: Exiting because of an unresolved conflict.
```

----------

## schorsch_76

This Problem with the mv overlay is most probably cause by rebase on the git repository. As a rule of thumb: "Never ever rebase any published branches".

As a git development model suitable for all of such issues:

http://nvie.com/posts/a-successful-git-branching-model/

----------

## mv

 *schorsch_76 wrote:*   

> This Problem with the mv overlay is most probably cause by rebase on the git repository

 

There was no rebase since the one announced on Oct 19.

----------

## mv

 *schorsch_76 wrote:*   

> As a rule of thumb: "Never ever rebase any published branches".

 

BTW, this rule might be useful for projects with many people involved and with kind of systematic QA before pushing to public - iit does not apply for experimental overlays managed by a single person where normally every change should go pulbic immediately (perhaps after a very crude testing).

But even for these other projects, it is only a rule of thumb. There might be good reasons why a bad history slipped through which should be eliminated forever:

A file unrelated to the project and copied by mistake from somewhere else by one developer (and slipped through QA) might be such a reason.

Not unnecessarily wasting disk space for known-to-be-broken commits is another reason.

A change of commit policy (as e.g. explained several postings ago) is yet another reason.

----------

## Massimo B.

Anyway, in the meanwhile I can't really work anymore concerning squashmount and git repos like the overlays. Curiously the big portage git repo doesn't have these issues. But as for the layman overlays almost every eix-sync is failing with tons of broken ebuilds like

```
ebuild failed with status 1

     Reading category  80|166 ( 48): kde-apps...

cannot properly execute /var/lib/layman/kde/kde-apps/okteta/okteta-9999.ebuild

     Reading category  80|166 ( 48): kde-apps.../var/lib/layman/kde/eclass/cmake-utils.eclass: line 67: syntax error near unexpected token `<<<'

/var/lib/layman/kde/eclass/cmake-utils.eclass: line 67: `<<<<<<< HEAD'
```

or

```
-- invalid line 141 in /var/lib/layman/kde/profiles/package.mask: "<<<<<<< ..."

    cannot read category

-- invalid line 142 in /var/lib/layman/kde/profiles/package.mask: "======= ..."

    cannot read category

-- invalid line 144 in /var/lib/layman/kde/profiles/package.mask: ">>>>>>> ..."

    cannot read category
```

As a short solution I currently need to flush all overlays before eix-sync which is not a long-time solution:

```
overlays="flavour kde mv sunrise";layman -d $overlays;layman -a $overlays
```

Can you take a look what is wrong with my setup? (I did not mention all mount points such as firefox, libreoffice, texlive etc.)

```

use Sys::Hostname;

my $hostname = ($ENV{'HOSTNAME'} // hostname());

@order = qw(overlay unionfs-fuse);

my $defaults = {

      COMPRESSION => 'lzo',

      THRESHOLD   => '10m',

};

my $non_binary = {

      COMPOPT_XZ => undef # "-Xbcj x86" is slower for pure text archives

};

@mounts = (

      standard_mount('layman',        '/var/lib/layman',      $defaults),

      standard_mount('local_portage', '/usr/local/portage',   $defaults),

      standard_mount('portage', '/usr/portage', $defaults, $non_binary, {

                  UMOUNT => ((@umount) ? undef : '-i'),

                  THRESHOLD => '100m',

                  FILL => qr{^local/(?!(?:\.git|profiles|metadata)(?:/|$))}

            }),

      standard_mount('db', '/var/db', $defaults, $non_binary, {

                  UMOUNT => ((@umount) ? undef : '-i'),

                  THRESHOLD => '40m',

                  BACKUP => '.bak'

            })

);

'EOF';

```

----------

## mv

 *Massimo B. wrote:*   

> 
> 
> ```
> "<<<<<<< ..."
> 
> ...

 

Such lines are caused by "git pull" when there are local changes or when the overlay was rebased. It has only to do with git/layman and nothing to do with squashmount.

----------

## Massimo B.

-> Moving on to the bug tracker: bug 500358#c3

----------

## Massimo B.

After some squashmount restart I end up with some hanging portage mount:

```
# squashmount status

 * [firefox]:       not mounted

 * [icedtea6]:      not mounted

 * [icedtea7]:      not mounted

 * [layman]:        not mounted

 * [libreoffice]:   not mounted

 * [local_portage]: incompletely mounted

 * [texmf]:         not mounted

 * [texlive_local]: not mounted

 * [portage]:       overlay (100m), unmodified

 * [ccache]:        not mounted

 * [db]:            not mounted

# squashmount remount --force portage --lsof=0

 * [portage]:       umounting...

umount: /usr/portage: not mounted

 * [portage]:       error:   non-lazy umount failed,

                             using lazy umount of /usr/portage

umount: /usr/portage: not mounted

 * [portage]:       error:   lazy umount failed for /usr/portage

# mount |grep portage |wc -l

0

# lsof /usr/portage |wc -l

0
```

Mounting manually worked:

```
# mount -o ro,noatime /usr/portage.mount/portage.sfs /usr/portage.mount/readonly

# mount -t overlay -o rw,noatime,lowerdir=/usr/portage.mount/readonly,upperdir=/usr/portage.mount/changes,workdir=/usr/portage.mount/workdir overlay /usr/portage
```

Now remounting works:

```
# squashmount remount --force portage

 * [portage]:       umounting...

 * [portage]:       cleaning workdir...

 * [portage]:       cleaning changes...

 * [portage]:       mounting...
```

----------

## mv

@Massimo B.: The problem is that there appears to be no reliable way to check whether a directory is mounted. The failure of the umounting thus is necessarily interpreted in the way that the directory might still be mounted, and if in such a case the underlying squash-file would be umounted hell might break loose.

If you are in a broken (half-mounted) state as above (which BTW you can reach only due to some exceptional error - mounting of several filesystems cannot be an "atomic" operation), you can combine --force with --ignore-state  (documented under --ignore-state with "squashmount man") which causes the failure of the umount to be ignored and to proceed with the further steps anyway.

----------

## schorsch_76

@mv: Just for your information: I use squashmount on the raspi 3 for portage. It works like expected but it is masked on arm.

```
raspberrypi3 pi # cat /etc/squashmount.pl 

#!/usr/bin/perl (this is only for editors)

# The tools which we have installed; if possible only the first in this list

# is used, but the others are a fallback if that fails.

@order = ('overlay');

# Even if we define following is empty it is convenient to use

# this local variable throughout, so that we can simply change it:

DIFF => 1;

#RESQUASH_ON_START => 1;

push(@mounts, 

{

   TAG => 'portage',

   DIR => '/usr/portage',

   FILE => '/usr/portage.sqfs',

   CHANGES => '/usr/portage.changes',

   READONLY => '/usr/portage.readonly',

   THRESHOLD => '40m', # resquash on umount if 40 megabytes changed

   COMPRESSION => 'gzip'

}

);

@umount = ('-i');

raspberrypi3 pi # cat /proc/cpuinfo 

processor   : 0

model name   : ARMv7 Processor rev 4 (v7l)

BogoMIPS   : 76.80

Features   : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 

CPU implementer   : 0x41

CPU architecture: 7

CPU variant   : 0x0

CPU part   : 0xd03

CPU revision   : 4

...

Hardware   : BCM2709

Revision   : a02082

raspberrypi3 pi # /etc/init.d/squashmount status

 * status: started

raspberrypi3 pi # mount | column -t | grep -v sys

/dev/mmcblk0p2     on  /                          type  ext4         (rw,noatime,data=ordered)

devtmpfs           on  /dev                       type  devtmpfs     (rw,nosuid,relatime,size=10240k,nr_inodes=117427,mode=755)

proc               on  /proc                      type  proc         (rw,nosuid,nodev,noexec,relatime)

tmpfs              on  /run                       type  tmpfs        (rw,nodev,relatime,size=94808k,mode=755)

mqueue             on  /dev/mqueue                type  mqueue       (rw,nosuid,nodev,noexec,relatime)

devpts             on  /dev/pts                   type  devpts       (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)

shm                on  /dev/shm                   type  tmpfs        (rw,nosuid,nodev,noexec,relatime)

/usr/portage.sqfs  on  /usr/portage.readonly      type  squashfs     (ro,noatime)

overlay            on  /usr/portage               type  overlay      (rw,noatime,lowerdir=/usr/portage.readonly,upperdir=/usr/portage.changes,workdir=/tmp/Z4xb2HWW3M)

/dev/mmcblk0p1     on  /boot                      type  vfat         (rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)

```

----------

## mv

 *schorsch_76 wrote:*   

> @mv: Just for your information: I use squashmount on the raspi 3 for portage. It works like expected but it is masked on arm.

 

squashmount is now marked for testing on the same arches as squashfs-tools from the gentoo repository

----------

## costel78

I have a small suggestion regarding optional dependencies of squashmount.

Instead:

```
 * Messages for package sys-fs/squashmount-14.1.1:

 *   app-shells/runtitle for status bar support

 *   dev-perl/File-Which for improved compatibility and security

 *   dev-perl/String-ShellQuote for improved output
```

and implicit some kind of "pollution" of world file I think a USEFLAG like "enhancement" to install those dependencies would be preferable.

What is your opinion ?

Thank you!

----------

## mv

 *costel78 wrote:*   

> I think a USEFLAG like "enhancement" to install those dependencies would be preferable.

 

I also think so, but it would go against gentoo policy: USE-flags are only admissible if they cause a change in the installed data. This is not the case here, since only the dependencies would be influenced.

----------

## costel78

I have to admit my total ignorance regarding Gentoo ebuild policies.   :Embarassed: 

As I presume there also are good reasons to not include dependencies by default, I can think of following solutions:

1. live with it, it is just a minor inconvenience;

2. keep in my local overlay a modified ebuild of your squashmount;

3. a virtual/squashmount, or a squashmount-meta package.

Thank you for your time and your work. I really appreciate.

----------

## mv

 *costel78 wrote:*   

> 1. live with it, it is just a minor inconvenience;
> 
> 2. keep in my local overlay a modified ebuild of your squashmount;
> 
> 3. a virtual/squashmount, or a squashmount-meta package.

 

For avoiding 1, I would never do 2 (as long as adding of dependencies is concerned; for removing dependencies, there is no other sane choice, unfortunately): It means you have to maintain the ebuild by yourself instead of just using layman.

3 is complete overkill for a public repository; this is something which you could put in your local overlay.

The mv overlay contains now some sets (which is perhaps more reasonable than 3, but it works only with portage, not necessarily with other package managers). Just call 

```
emerge --deselect squashmount && emerge --select -n @squashmount
```

 to put the set instead of the package into the world file.

(If the overlay would not provide the sets/... file you could just create it by your own in /etc/portage/sets/ to use the same thing).

----------

## costel78

A elegant solution. 

Thank you!

----------

## mv

Announcement:

squashmount-15.0.0 can now also be used without root permissions!

Look for --user in squashmount man

This requires of course that fuse is used for all mounting operations. In particular, this is possible now because

squahsmount-15.0.0 also supports squashfuse

----------

## costel78

Is there something wrong with this config file ?

```
#!/usr/bin/perl (this is only for editors)

use Sys::Hostname;

my $hostname = ($ENV{'HOSTNAME'} // hostname());

@order = qw(overlay overlayfs aufs! unionfs-fuse! unionfs??# funionfs??#);

$obsolete_overlayfs = undef;

$rm_changes = $rm_workdir = $rm_readonly = 0;

my $defaults = {

   COMPRESSION => 'lz4',

   COMPOPT_LZ4 => '-Xhc'

};

my $non_binary = {

   COMPOPT_XZ => undef  

};

@mounts = (

   added_hash($defaults, $non_binary,  {

      TAG => 'db',

      DIR => '/var/db',

      FILE => '/var/db.mount/db.sfs',

      CHANGES => '/var/db.mount/changes',

      WORKDIR => '/var/db.mount/workdir',

      READONLY => '/var/db.mount/readonly',

      THRESHOLD => '30m',

      BLOCKSIZE => 65536

   }),

   added_hash($defaults, $non_binary, {

      TAG => 'portage',

      DIR => '/usr/portage',

      FILE => '/usr/portage.mount/db.sfs',

      CHANGES => '/usr/portage.mount/changes',

      WORKDIR => '/usr/portage.mount/workdir',

      READONLY => '/usr/portage.mount/readonly',

      THRESHOLD => '80m',

      BLOCKSIZE => 65536,

      UMOUNT => ((@umount) ? undef : '-i'),

      FILL => qr{^local/(?!(\.git|profiles|metadata)(/|$))}n

   })

);

$after_mount = sub {

   my ($mountpoint, $store, $config) = @_;

   return 1 unless($mountpoint eq 'portage');

   system('mount', '--bind', $config->{DIR} // $store->{DIR}, '/srv/copy');

   1  # return a true value!

};

$before_umount = sub {

   my ($mountpoint, $store, $config) = @_;

   return 1 unless($mountpoint eq 'portage');

   system('umount /srv/copy');

   1

};

$before_mount = sub {

   my ($mountpoint, $store, $config) = @_;

   return 1 unless($mountpoint eq 'portage');

   system('umount /srv/copy >/dev/null 2>&1');

   1

};

1;
```

I keep getting a lot of "Permission denied" messages, on emerge --sync.

I tried with a fresh copy of portage and db and there is the same result:

```
aug 08 19:34:09 gentoo squashmount[14818]:  * [portage]: error:   (while removing /usr/portage/x11-libs/gtkhotkey/metadata.xml): cannot unlink file: Permission denied

aug 08 19:34:09 gentoo squashmount[14818]:  * [portage]: error:   (while removing /usr/portage/x11-libs/gtkhotkey/metadata.xml): cannot restore permissions to 0100644: Permission denied

aug 08 19:34:09 gentoo squashmount[14818]:  * [portage]: error:   (while removing /usr/portage/x11-libs/gtkhotkey/ChangeLog-2015): cannot unlink file: Permission denied

aug 08 19:34:09 gentoo squashmount[14818]:  * [portage]: error:   (while removing /usr/portage/x11-libs/gtkhotkey/ChangeLog-2015): cannot restore permissions to 0100644: Permission denied

aug 08 19:34:09 gentoo squashmount[14818]:  * [portage]: error:   (while removing /usr/portage/x11-libs/gtkhotkey/gtkhotkey-0.2.1.ebuild): cannot unlink file: Permission denied

aug 08 19:34:09 gentoo squashmount[14818]:  * [portage]: error:   (while removing /usr/portage/x11-libs/gtkhotkey/gtkhotkey-0.2.1.ebuild): cannot restore permissions to 0100644: Permission denied

aug 08 19:34:09 gentoo squashmount[14818]:  * [portage]: error:   (while removing /usr/portage/x11-libs/gtkhotkey/Manifest): cannot unlink file: Permission denied

aug 08 19:34:09 gentoo squashmount[14818]:  * [portage]: error:   (while removing /usr/portage/x11-libs/gtkhotkey/Manifest): cannot restore permissions to 0100644: Permission denied

aug 08 19:34:09 gentoo squashmount[14818]:  * [portage]: error:   (while removing /usr/portage/x11-libs/gtkhotkey): cannot remove directory: Permission denied

aug 08 19:34:09 gentoo squashmount[14818]:  * [portage]: error:   (while removing /usr/portage/x11-libs): cannot remove directory: Directory not empty

```

Majority of the files are owned by root, some by portage. The issue started from 15.0 version.

I am using default squashmount.service with root permission:

```
[Unit]

Description=mount/umount all squashmount configured mount points

After=local-fs.target systemd-tmpfiles-setup.service

[Service]

# Squashing can take a long time. It is recommended to override the following

# long timeout in /etc/systemd/system/squashmount.service.d/timeout.conf

TimeoutStopSec=1800

Type=oneshot

CapabilityBoundingSet=

CapabilityBoundingSet=CAP_SYS_ADMIN

CapabilityBoundingSet=CAP_CHOWN

CapabilityBoundingSet=CAP_SYS_MODULE

MemoryDenyWriteExecute=true

NoNewPrivileges=true

PrivateNetwork=true

RemainAfterExit=true

ExecStart=/usr/bin/squashmount start

ExecStop=/usr/bin/squashmount -f --lsof=0 --lsof-ro=0 stop

[Install]

WantedBy=multi-user.target
```

I can't figure out what I'm missing. Thank you!

----------

## mv

 *costel78 wrote:*   

> Is there something wrong with this config file ?

 

I cannot see an obvious problem.

Concerning the permissions, it might be an accident that it happened with the change to 15.0. I conjecture, a (known) problem in overlay is the reason; I have reported it, but I am not sure whether it is solved meanwhile: There was a problem when removing files after renaming directories (which can happens after syncing for a package move); some special device (normally indicating removed files) in the renamed directory appear as special devices and are impossible to remove in overlay: They must be removed in the CHANGES directory manually.

Check whether you can remove the indicated files manually (as root) and what type this files actually possess.

If this is not the reason: When exactly do these errors pop up, and what is the output of squashmount -vvv list

----------

## costel78

```
gentoo ~ # squashmount -vvv list

 * squashmount: reading config file /etc/squashmount.pl

 * [db]:      overlay/squashfs

              unmodified

              THRESHOLD: 31457280

              DIR: /var/db

              READONLY: /var/db.mount/readonly

              CHANGES: /var/db.mount/changes

              WORKDIR: /var/db.mount/workdir

              FILE: /var/db.mount/db.sfs

              mksquashfs-options: -noappend -quiet -comp lz4 -Xhc

              CHMOD: 0644

              CHOWN: unchanged (0:0)

              CHMOD_DIR: unchanged

              CHOWN_DIR: unchanged

 * [portage]: overlay/squashfs

              unmodified

              THRESHOLD: 83886080

              DIR: /usr/portage

              READONLY: /usr/portage.mount/readonly

              CHANGES: /usr/portage.mount/changes

              WORKDIR: /usr/portage.mount/workdir

              FILE: /usr/portage.mount/db.sfs

              mksquashfs-options: -noappend -quiet -comp lz4 -Xhc

              CHMOD: 0644

              CHOWN: unchanged (0:0)

              CHMOD_DIR: unchanged

              CHOWN_DIR: unchanged
```

Errors during emerge --sync:

```
gentoo ~ # emerge --sync

>>> Syncing repository 'gentoo' into '/usr/portage'...

>>> Starting rsync with rsync://91.186.30.235/gentoo-portage...

Welcome to boobie.gentoo.org / rsync.gentoo.org

Server Address : 

Contact Name   : mirror-admin@gentoo.org

Hardware       : 2 x Intel(R) Xeon(R) CPU 3050 @ 2.13GHz, 3956MB RAM

Sponsor        : EUKhost, Maidenhead, England

Please note: common gentoo-netiquette says you should not sync more

than once a day.  Users who abuse the rsync.gentoo.org rotation

may be added to a temporary ban list.

MOTD autogenerated by update-rsync-motd on Thu Jul 24 06:32:46 UTC 2014

receiving file list ... 

1 file to consider

timestamp.chk

             32 100%   31.25kB/s    0:00:00 (xfr#1, to-chk=0/1)

Number of files: 1 (reg: 1)

Number of created files: 0

Number of deleted files: 0

Number of regular files transferred: 1

Total file size: 32 bytes

Total transferred file size: 32 bytes

Literal data: 32 bytes

Matched data: 0 bytes

File list size: 39

File list generation time: 0.001 seconds

File list transfer time: 0.000 seconds

Total bytes sent: 100

Total bytes received: 126

sent 100 bytes  received 126 bytes  150.67 bytes/sec

total size is 32  speedup is 0.14

Welcome to boobie.gentoo.org / rsync.gentoo.org

Server Address : 

Contact Name   : mirror-admin@gentoo.org

Hardware       : 2 x Intel(R) Xeon(R) CPU 3050 @ 2.13GHz, 3956MB RAM

Sponsor        : EUKhost, Maidenhead, England

Please note: common gentoo-netiquette says you should not sync more

than once a day.  Users who abuse the rsync.gentoo.org rotation

may be added to a temporary ban list.

MOTD autogenerated by update-rsync-motd on Thu Jul 24 06:32:46 UTC 2014

receiving file list ... 

204614 files to consider

rsync: delete_file: unlink(app-text/XML-Schema-learner/XML-Schema-learner-1.0.0.ebuild) failed: Permission denied (13)

rsync: delete_file: unlink(dev-lang/coffee-script/coffee-script-1.10.0.ebuild) failed: Permission denied (13)

rsync: delete_file: unlink(dev-ruby/multi_json/multi_json-1.12.0.ebuild) failed: Permission denied (13)

rsync: delete_file: unlink(dev-ruby/multi_json/multi_json-1.11.3.ebuild) failed: Permission denied (13)

rsync: delete_file: unlink(kde-apps/kgamma/files/kgamma-4.14.3-cmake34.patch) failed: Permission denied (13)

cannot delete non-empty directory: kde-apps/kgamma/files

rsync: delete_file: rmdir(kde-apps/kgamma/files) failed: Permission denied (13)

rsync: delete_file: unlink(kde-apps/kgamma/metadata.xml) failed: Permission denied (13)

rsync: delete_file: unlink(kde-apps/kgamma/kgamma-4.14.3.ebuild) failed: Permission denied (13)

rsync: delete_file: unlink(kde-apps/kgamma/Manifest) failed: Permission denied (13)

rsync: delete_file: unlink(kde-apps/kgamma/ChangeLog-2015) failed: Permission denied (13)

rsync: delete_file: unlink(kde-apps/kgamma/ChangeLog) failed: Permission denied (13)

cannot delete non-empty directory: kde-apps/kgamma

rsync: delete_file: unlink(mail-filter/pypolicyd-spf/pypolicyd-spf-1.3.1.ebuild) failed: Permission denied (13)

rsync: delete_file: unlink(mail-filter/pypolicyd-spf/pypolicyd-spf-1.1.ebuild) failed: Permission denied (13)

rsync: delete_file: unlink(metadata/md5-cache/app-text/XML-Schema-learner-1.0.0) failed: Permission denied (13)

rsync: delete_file: unlink(metadata/md5-cache/dev-lang/coffee-script-1.10.0) failed: Permission denied (13)

rsync: delete_file: unlink(metadata/md5-cache/dev-ruby/multi_json-1.12.0) failed: Permission denied (13)

rsync: delete_file: unlink(metadata/md5-cache/dev-ruby/multi_json-1.11.3) failed: Permission denied (13)

rsync: delete_file: unlink(metadata/md5-cache/kde-apps/kgamma-4.14.3) failed: Permission denied (13)

rsync: delete_file: unlink(metadata/md5-cache/mail-filter/pypolicyd-spf-1.3.1) failed: Permission denied (13)

rsync: delete_file: unlink(metadata/md5-cache/mail-filter/pypolicyd-spf-1.1) failed: Permission denied (13)

rsync: delete_file: unlink(metadata/md5-cache/net-analyzer/nagios-check_mysql_health-2.1.8.2) failed: Permission denied (13)

rsync: delete_file: unlink(metadata/md5-cache/net-analyzer/monitoring-plugins-2.1.1) failed: Permission denied (13)

rsync: delete_file: unlink(metadata/md5-cache/net-mail/postfix-logwatch-1.40.00) failed: Permission denied (13)

rsync: delete_file: unlink(metadata/md5-cache/sci-mathematics/octave-4.0.2-r1) failed: Permission denied (13)

rsync: delete_file: unlink(metadata/md5-cache/sci-mathematics/octave-3.8.2) failed: Permission denied (13)

rsync: delete_file: unlink(net-analyzer/monitoring-plugins/monitoring-plugins-2.1.1.ebuild) failed: Permission denied (13)

rsync: delete_file: unlink(net-analyzer/nagios-check_mysql_health/nagios-check_mysql_health-2.1.8.2.ebuild) failed: Permission denied (13)

rsync: delete_file: unlink(net-mail/postfix-logwatch/postfix-logwatch-1.40.00.ebuild) failed: Permission denied (13)

rsync: delete_file: unlink(sci-mathematics/octave/octave-4.0.2-r1.ebuild) failed: Permission denied (13)

rsync: delete_file: unlink(sci-mathematics/octave/octave-3.8.2.ebuild) failed: Permission denied (13)

rsync: mkstemp "/usr/portage/app-text/XML-Schema-learner/.Manifest.B4OLq0" failed: Permission denied (13)

          1.84K 100%    1.80MB/s    0:00:00 (xfr#1, to-chk=185530/204614)

rsync: mkstemp "/usr/portage/dev-lang/coffee-script/.Manifest.87ByuM" failed: Permission denied (13)

          2.60K 100%    2.54MB/s    0:00:00 (xfr#2, to-chk=168896/204614)

rsync: mkstemp "/usr/portage/dev-lang/coffee-script/.coffee-script-1.10.0-r1.ebuild.M0ioyy" failed: Permission denied (13)

          1.10K 100%    1.08MB/s    0:00:00 (xfr#3, to-chk=168895/204614)

rsync: mkstemp "/usr/portage/dev-ruby/httpclient/.Manifest.9dkfCk" failed: Permission denied (13)

          4.81K 100%    4.70MB/s    0:00:00 (xfr#4, to-chk=134168/204614)

rsync: mkstemp "/usr/portage/dev-ruby/httpclient/.httpclient-2.8.1.ebuild.och8F6" failed: Permission denied (13)

          1.72K 100%    1.68MB/s    0:00:00 (xfr#5, to-chk=134163/204614)

rsync: mkstemp "/usr/portage/dev-ruby/multi_json/.Manifest.StY2JS" failed: Permission denied (13)

          4.08K 100%   81.54kB/s    0:00:00 (xfr#6, to-chk=133610/204614)

rsync: mkstemp "/usr/portage/dev-ruby/multi_json/.multi_json-1.11.2.ebuild.Jxco1E" failed: Permission denied (13)

          1.88K 100%   37.64kB/s    0:00:00 (xfr#7, to-chk=133608/204614)

rsync: mkstemp "/usr/portage/dev-ruby/multi_json/.multi_json-1.12.1.ebuild.UP4Jir" failed: Permission denied (13)

          1.87K 100%   37.32kB/s    0:00:00 (xfr#8, to-chk=133607/204614)

rsync: mkstemp "/usr/portage/dev-ruby/multi_json/.multi_json-1.9.3.ebuild.CsZaAd" failed: Permission denied (13)

          1.83K 100%   36.66kB/s    0:00:00 (xfr#9, to-chk=133606/204614)

rsync: mkstemp "/usr/portage/dev-ruby/rspec-retry/.Manifest.sOzCRZ" failed: Permission denied (13)

          2.21K 100%   44.18kB/s    0:00:00 (xfr#10, to-chk=132561/204614)

rsync: mkstemp "/usr/portage/dev-ruby/rspec-retry/.rspec-retry-0.5.0.ebuild.KMm78L" failed: Permission denied (13)

            664 100%   12.97kB/s    0:00:00 (xfr#11, to-chk=132558/204614)

rsync: mkstemp "/usr/portage/dev-ruby/syntax/.Manifest.4aRCqy" failed: Permission denied (13)

          2.94K 100%   58.77kB/s    0:00:00 (xfr#12, to-chk=131651/204614)

rsync: mkstemp "/usr/portage/dev-ruby/syntax/.syntax-1.2.1.ebuild.xosdIk" failed: Permission denied (13)

            911 100%   17.44kB/s    0:00:00 (xfr#13, to-chk=131648/204614)

rsync: mkstemp "/usr/portage/dev-util/jenkins-bin/.Manifest.P8BQZ6" failed: Permission denied (13)

          5.54K 100%  108.67kB/s    0:00:00 (xfr#14, to-chk=127547/204614)

rsync: mkstemp "/usr/portage/dev-util/jenkins-bin/.jenkins-bin-2.11.ebuild.3qeEhT" failed: Permission denied (13)

          1.08K 100%   21.25kB/s    0:00:00 (xfr#15, to-chk=127545/204614)

rsync: mkstemp "/usr/portage/dev-util/jenkins-bin/.jenkins-bin-2.12.ebuild.N9YszF" failed: Permission denied (13)

          1.09K 100%   20.88kB/s    0:00:00 (xfr#16, to-chk=127544/204614)

rsync: mkstemp "/usr/portage/mail-filter/pypolicyd-spf/.Manifest.mrClRr" failed: Permission denied (13)

          1.84K 100%   35.34kB/s    0:00:00 (xfr#17, to-chk=110496/204614)

rsync: mkstemp "/usr/portage/media-libs/libsfml/.Manifest.eAZe9d" failed: Permission denied (13)

          2.95K 100%   56.64kB/s    0:00:00 (xfr#18, to-chk=103807/204614)

rsync: mkstemp "/usr/portage/media-libs/libsfml/.libsfml-2.4.0.ebuild.KTVcr0" failed: Permission denied (13)

          1.44K 100%   14.40kB/s    0:00:00 (xfr#19, to-chk=103805/204614)

rsync: mkstemp "/usr/portage/metadata/.layout.conf.YRVaWM" failed: Permission denied (13)

          1.42K 100%   14.23kB/s    0:00:00 (xfr#20, to-chk=94392/204614)

rsync: mkstemp "/usr/portage/metadata/.projects.xml.roYbrz" failed: Permission denied (13)

        137.67K 100%  865.82kB/s    0:00:00 (xfr#21, to-chk=94391/204614)

rsync: mkstemp "/usr/portage/metadata/.timestamp.4s99bm" failed: Permission denied (13)

             29 100%    0.18kB/s    0:00:00 (xfr#22, to-chk=94390/204614)

rsync: mkstemp "/usr/portage/metadata/.timestamp.chk.AQEaX8" failed: Permission denied (13)

             32 100%    0.20kB/s    0:00:00 (xfr#23, to-chk=94389/204614)

rsync: mkstemp "/usr/portage/metadata/.timestamp.x.6hHcIV" failed: Permission denied (13)

             43 100%    0.26kB/s    0:00:00 (xfr#24, to-chk=94388/204614)

rsync: mkstemp "/usr/portage/metadata/dtd/.timestamp.chk.QB9ftI" failed: Permission denied (13)

             32 100%    0.20kB/s    0:00:00 (xfr#25, to-chk=94374/204614)

rsync: mkstemp "/usr/portage/metadata/glsa/.timestamp.chk.RFBlev" failed: Permission denied (13)

             32 100%    0.20kB/s    0:00:00 (xfr#26, to-chk=92135/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/dev-lang/.coffee-script-1.10.0-r1.Tl1sZh" failed: Permission denied (13)

            348 100%    2.14kB/s    0:00:00 (xfr#27, to-chk=83997/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/dev-ruby/.httpclient-2.8.1.kSvCK4" failed: Permission denied (13)

          3.94K 100%   24.62kB/s    0:00:00 (xfr#28, to-chk=74545/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/dev-ruby/.multi_json-1.11.2.0elPvR" failed: Permission denied (13)

          3.63K 100%   22.66kB/s    0:00:00 (xfr#29, to-chk=74390/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/dev-ruby/.multi_json-1.12.1.4fW4gE" failed: Permission denied (13)

          4.49K 100%   28.09kB/s    0:00:00 (xfr#30, to-chk=74389/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/dev-ruby/.multi_json-1.9.3.tcFo2q" failed: Permission denied (13)

          2.78K 100%   17.38kB/s    0:00:00 (xfr#31, to-chk=74388/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/dev-ruby/.rspec-retry-0.5.0.1s7ONd" failed: Permission denied (13)

          3.20K 100%   19.86kB/s    0:00:00 (xfr#32, to-chk=74084/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/dev-ruby/.syntax-1.2.1.bIllz0" failed: Permission denied (13)

          2.98K 100%   18.52kB/s    0:00:00 (xfr#33, to-chk=73772/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/dev-util/.jenkins-bin-2.11.xdfTkN" failed: Permission denied (13)

            611 100%    3.71kB/s    0:00:00 (xfr#34, to-chk=72753/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/dev-util/.jenkins-bin-2.12.icIy6z" failed: Permission denied (13)

            613 100%    3.72kB/s    0:00:00 (xfr#35, to-chk=72752/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/media-libs/.libsfml-2.4.0.8fdgSm" failed: Permission denied (13)

          1.23K 100%    7.61kB/s    0:00:00 (xfr#36, to-chk=68062/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/net-analyzer/.nagios-check_mysql_health-2.2.2.4Qy0D9" failed: Permission denied (13)

            452 100%    2.72kB/s    0:00:00 (xfr#37, to-chk=65822/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/sci-mathematics/.octave-3.6.4.oPGNpW" failed: Permission denied (13)

          2.60K 100%   16.03kB/s    0:00:00 (xfr#38, to-chk=61393/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/sci-mathematics/.octave-3.6.4-r1.JvDDbJ" failed: Permission denied (13)

          2.63K 100%   13.15kB/s    0:00:00 (xfr#39, to-chk=61392/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/sci-mathematics/.octave-3.8.2-r1.5gvT7v" failed: Permission denied (13)

          3.33K 100%   16.57kB/s    0:00:00 (xfr#40, to-chk=61391/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/sci-mathematics/.octave-4.0.0.Mmrc4i" failed: Permission denied (13)

          3.55K 100%   17.67kB/s    0:00:00 (xfr#41, to-chk=61390/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/sci-mathematics/.octave-4.0.0-r1.GSJy05" failed: Permission denied (13)

          3.55K 100%   17.67kB/s    0:00:00 (xfr#42, to-chk=61389/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/sci-mathematics/.octave-4.0.1.UkuZWS" failed: Permission denied (13)

          3.55K 100%   17.67kB/s    0:00:00 (xfr#43, to-chk=61388/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/sci-mathematics/.octave-4.0.1-r1.hC2xTF" failed: Permission denied (13)

          3.55K 100%   17.58kB/s    0:00:00 (xfr#44, to-chk=61387/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/sci-mathematics/.octave-4.0.2-r2.cJdcQs" failed: Permission denied (13)

          3.55K 100%   17.58kB/s    0:00:00 (xfr#45, to-chk=61386/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/sys-apps/.diffutils-3.4.dcwZMf" failed: Permission denied (13)

            895 100%    4.31kB/s    0:00:00 (xfr#46, to-chk=59484/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/sys-kernel/.rt-sources-3.14.65_p68.rdKPJ2" failed: Permission denied (13)

          1.46K 100%    7.17kB/s    0:00:00 (xfr#47, to-chk=57418/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/sys-kernel/.rt-sources-3.14.72_p75.kEjIGP" failed: Permission denied (13)

          1.46K 100%    7.17kB/s    0:00:00 (xfr#48, to-chk=57417/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/sys-kernel/.rt-sources-3.18.29_p30.piLCDC" failed: Permission denied (13)

          1.46K 100%    7.17kB/s    0:00:00 (xfr#49, to-chk=57416/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/sys-kernel/.rt-sources-3.18.36_p37.bTDyAp" failed: Permission denied (13)

          1.46K 100%    7.17kB/s    0:00:00 (xfr#50, to-chk=57415/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/sys-kernel/.rt-sources-4.1.20_p23.Mrtyxc" failed: Permission denied (13)

          1.44K 100%    7.11kB/s    0:00:00 (xfr#51, to-chk=57414/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/sys-kernel/.rt-sources-4.1.27_p30.FQPzuZ" failed: Permission denied (13)

          1.44K 100%    7.11kB/s    0:00:00 (xfr#52, to-chk=57413/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/sys-kernel/.rt-sources-4.4.12_p19.SRUDrM" failed: Permission denied (13)

          1.44K 100%    7.11kB/s    0:00:00 (xfr#53, to-chk=57412/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/sys-kernel/.rt-sources-4.4.9_p17.JZnJoz" failed: Permission denied (13)

          1.44K 100%    7.06kB/s    0:00:00 (xfr#54, to-chk=57411/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/sys-kernel/.rt-sources-4.6.1_p3.0aNRlm" failed: Permission denied (13)

          1.44K 100%    7.04kB/s    0:00:00 (xfr#55, to-chk=57410/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/sys-kernel/.rt-sources-4.6.2_p5.wTP1i9" failed: Permission denied (13)

          1.44K 100%    7.04kB/s    0:00:00 (xfr#56, to-chk=57409/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/sys-process/.cronie-1.5.1.mindgW" failed: Permission denied (13)

          1.05K 100%    5.14kB/s    0:00:00 (xfr#57, to-chk=57010/204614)

rsync: mkstemp "/usr/portage/metadata/md5-cache/www-servers/.nginx-1.11.3.HkptdJ" failed: Permission denied (13)

          8.87K 100%   43.27kB/s    0:00:00 (xfr#58, to-chk=55979/204614)

rsync: mkstemp "/usr/portage/metadata/news/.timestamp.chk.oMr3aw" failed: Permission denied (13)

             32 100%    0.15kB/s    0:00:00 (xfr#59, to-chk=53931/204614)

rsync: mkstemp "/usr/portage/metadata/xml-schema/.timestamp.chk.KG4F8i" failed: Permission denied (13)

             32 100%    0.15kB/s    0:00:00 (xfr#60, to-chk=53675/204614)

rsync: mkstemp "/usr/portage/net-analyzer/monitoring-plugins/.Manifest.OK2k65" failed: Permission denied (13)

          1.85K 100%    8.96kB/s    0:00:00 (xfr#61, to-chk=52637/204614)

rsync: mkstemp "/usr/portage/net-analyzer/nagios-check_mysql_health/.Manifest.5w523S" failed: Permission denied (13)

          2.63K 100%   12.75kB/s    0:00:00 (xfr#62, to-chk=52516/204614)

rsync: mkstemp "/usr/portage/net-analyzer/nagios-check_mysql_health/.nagios-check_mysql_health-2.2.2.ebuild.03oN1F" failed: Permission denied (13)

          1.12K 100%    5.45kB/s    0:00:00 (xfr#63, to-chk=52513/204614)

rsync: mkstemp "/usr/portage/net-mail/postfix-logwatch/.Manifest.afVyZs" failed: Permission denied (13)

          1.84K 100%    8.94kB/s    0:00:00 (xfr#64, to-chk=45228/204614)

rsync: mkstemp "/usr/portage/net-mail/postfix-logwatch/.metadata.xml.7yhmXf" failed: Permission denied (13)

            304 100%    1.44kB/s    0:00:00 (xfr#65, to-chk=45227/204614)

rsync: mkstemp "/usr/portage/profiles/.use.local.desc.yIyaV2" failed: Permission denied (13)

        676.28K 100%    2.01MB/s    0:00:00 (xfr#66, to-chk=37727/204614)

rsync: mkstemp "/usr/portage/profiles/desc/.nginx_modules_http.desc.vhH0pQ" failed: Permission denied (13)

          6.03K 100%   18.33kB/s    0:00:00 (xfr#67, to-chk=36516/204614)

rsync: mkstemp "/usr/portage/profiles/desc/.nginx_modules_stream.desc.DQx1UD" failed: Permission denied (13)

          1.35K 100%    4.11kB/s    0:00:00 (xfr#68, to-chk=36514/204614)

rsync: mkstemp "/usr/portage/profiles/updates/.3Q-2016.5ns4pr" failed: Permission denied (13)

            656 100%    1.95kB/s    0:00:00 (xfr#69, to-chk=35204/204614)

rsync: mkstemp "/usr/portage/sci-mathematics/octave/.Manifest.URq9Ue" failed: Permission denied (13)

         12.00K 100%   36.37kB/s    0:00:00 (xfr#70, to-chk=28097/204614)

rsync: mkstemp "/usr/portage/sci-mathematics/octave/.octave-3.6.4-r1.ebuild.T4UAq2" failed: Permission denied (13)

          3.40K 100%   10.29kB/s    0:00:00 (xfr#71, to-chk=28095/204614)

rsync: mkstemp "/usr/portage/sci-mathematics/octave/.octave-3.6.4.ebuild.Exo4VP" failed: Permission denied (13)

          3.33K 100%   10.08kB/s    0:00:00 (xfr#72, to-chk=28094/204614)

rsync: mkstemp "/usr/portage/sci-mathematics/octave/.octave-3.8.2-r1.ebuild.oEZIrD" failed: Permission denied (13)

          4.18K 100%   12.63kB/s    0:00:00 (xfr#73, to-chk=28093/204614)

rsync: mkstemp "/usr/portage/sci-mathematics/octave/.octave-4.0.0-r1.ebuild.s06rXq" failed: Permission denied (13)

          4.87K 100%   14.66kB/s    0:00:00 (xfr#74, to-chk=28092/204614)

rsync: mkstemp "/usr/portage/sci-mathematics/octave/.octave-4.0.0.ebuild.SL2kte" failed: Permission denied (13)

          4.55K 100%   12.96kB/s    0:00:00 (xfr#75, to-chk=28091/204614)

rsync: mkstemp "/usr/portage/sci-mathematics/octave/.octave-4.0.1-r1.ebuild.qGwq41" failed: Permission denied (13)

          4.70K 100%   13.36kB/s    0:00:00 (xfr#76, to-chk=28090/204614)

rsync: mkstemp "/usr/portage/sci-mathematics/octave/.octave-4.0.1.ebuild.OFoIFP" failed: Permission denied (13)

          4.55K 100%   12.93kB/s    0:00:00 (xfr#77, to-chk=28089/204614)

rsync: mkstemp "/usr/portage/sci-mathematics/octave/.octave-4.0.2-r2.ebuild.NWG7gD" failed: Permission denied (13)

          4.70K 100%   13.33kB/s    0:00:00 (xfr#78, to-chk=28088/204614)

rsync: mkstemp "/usr/portage/sys-apps/diffutils/.Manifest.ZquGSq" failed: Permission denied (13)

          2.57K 100%    7.26kB/s    0:00:00 (xfr#79, to-chk=23586/204614)

rsync: mkstemp "/usr/portage/sys-apps/diffutils/.diffutils-3.4.ebuild.YwPtue" failed: Permission denied (13)

          1.25K 100%    3.54kB/s    0:00:00 (xfr#80, to-chk=23584/204614)

rsync: mkstemp "/usr/portage/sys-kernel/rt-sources/.Manifest.akui61" failed: Permission denied (13)

         17.80K 100%   49.99kB/s    0:00:00 (xfr#81, to-chk=15390/204614)

rsync: mkstemp "/usr/portage/sys-kernel/rt-sources/.rt-sources-3.14.65_p68.ebuild.lDeIIP" failed: Permission denied (13)

          1.26K 100%    3.55kB/s    0:00:00 (xfr#82, to-chk=15388/204614)

rsync: mkstemp "/usr/portage/sys-kernel/rt-sources/.rt-sources-3.14.72_p75.ebuild.EWWclD" failed: Permission denied (13)

          1.26K 100%    3.55kB/s    0:00:00 (xfr#83, to-chk=15387/204614)

rsync: mkstemp "/usr/portage/sys-kernel/rt-sources/.rt-sources-3.18.29_p30.ebuild.lxsIXq" failed: Permission denied (13)

          1.26K 100%    3.55kB/s    0:00:00 (xfr#84, to-chk=15386/204614)

rsync: mkstemp "/usr/portage/sys-kernel/rt-sources/.rt-sources-3.18.36_p37.ebuild.GsBeAe" failed: Permission denied (13)

          1.26K 100%    3.55kB/s    0:00:00 (xfr#85, to-chk=15385/204614)

rsync: mkstemp "/usr/portage/sys-kernel/rt-sources/.rt-sources-4.1.20_p23.ebuild.7muLc2" failed: Permission denied (13)

          1.26K 100%    3.55kB/s    0:00:00 (xfr#86, to-chk=15384/204614)

rsync: mkstemp "/usr/portage/sys-kernel/rt-sources/.rt-sources-4.1.27_p30.ebuild.p7blPP" failed: Permission denied (13)

          1.26K 100%    3.55kB/s    0:00:00 (xfr#87, to-chk=15383/204614)

rsync: mkstemp "/usr/portage/sys-kernel/rt-sources/.rt-sources-4.4.12_p19.ebuild.FKBVrD" failed: Permission denied (13)

          1.26K 100%    3.54kB/s    0:00:00 (xfr#88, to-chk=15382/204614)

rsync: mkstemp "/usr/portage/sys-kernel/rt-sources/.rt-sources-4.4.9_p17.ebuild.SgaA4q" failed: Permission denied (13)

          1.26K 100%    3.54kB/s    0:00:00 (xfr#89, to-chk=15381/204614)

rsync: mkstemp "/usr/portage/sys-kernel/rt-sources/.rt-sources-4.6.1_p3.ebuild.0xVfHe" failed: Permission denied (13)

          1.26K 100%    3.54kB/s    0:00:00 (xfr#90, to-chk=15380/204614)

rsync: mkstemp "/usr/portage/sys-kernel/rt-sources/.rt-sources-4.6.2_p5.ebuild.r2zWj2" failed: Permission denied (13)

          1.26K 100%    3.54kB/s    0:00:00 (xfr#91, to-chk=15379/204614)

rsync: mkstemp "/usr/portage/sys-process/cronie/.Manifest.UplHWP" failed: Permission denied (13)

          4.76K 100%   13.34kB/s    0:00:00 (xfr#92, to-chk=13834/204614)

rsync: mkstemp "/usr/portage/sys-process/cronie/.cronie-1.5.1.ebuild.MRxwzD" failed: Permission denied (13)

          2.08K 100%    5.82kB/s    0:00:00 (xfr#93, to-chk=13831/204614)

rsync: mkstemp "/usr/portage/www-servers/nginx/.Manifest.05rrcr" failed: Permission denied (13)

         14.70K 100%   40.94kB/s    0:00:00 (xfr#94, to-chk=9468/204614)

rsync: mkstemp "/usr/portage/www-servers/nginx/.nginx-1.11.3.ebuild.mUnJPe" failed: Permission denied (13)

         28.14K 100%   77.51kB/s    0:00:00 (xfr#95, to-chk=9463/204614)

rsync: mkstemp "/usr/portage/www-servers/nginx/files/.nginx-1.11.3-fix-build-without-stream_ssl_module.patch.1lTau2" failed: Permission denied (13)

            873 100%    2.35kB/s    0:00:00 (xfr#96, to-chk=9460/204614)

Number of files: 204,614 (reg: 177,248, dir: 27,366)

Number of created files: 25 (reg: 25)

Number of deleted files: 0

Number of regular files transferred: 96

Total file size: 391.91M bytes

Total transferred file size: 1.06M bytes

Literal data: 1.06M bytes

Matched data: 0 bytes

File list size: 4.68M

File list generation time: 1.138 seconds

File list transfer time: 0.000 seconds

Total bytes sent: 1.93K

Total bytes received: 5.74M

sent 1.93K bytes  received 5.74M bytes  1.27M bytes/sec

total size is 391.91M  speedup is 68.31

rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1650) [generator=3.1.2]

>>> Retrying...

>>> Starting retry 1 of 4 with rsync://81.91.253.252/gentoo-portage

```

```
gentoo portage # ls -als

total 18

4 drwxr-xr-x    1 root    root     4096 aug  9 10:58 .

4 drwxr-xr-x   17 root    root     4096 aug  9 10:57 ..

0 drwxr-xr-x   40 portage portage   704 iul 27 11:35 app-accessibility

0 drwxr-xr-x  198 portage portage  3446 aug  7 19:18 app-admin

0 drwxr-xr-x    5 portage portage    94 iul 27 11:35 app-antivirus

0 drwxr-xr-x  103 portage portage  1499 iul 27 11:35 app-arch

0 drwxr-xr-x   62 portage portage  1162 aug  1 12:27 app-backup

0 drwxr-xr-x   35 portage portage   557 iul 27 11:35 app-benchmarks

0 drwxr-xr-x   63 portage portage  1012 iul 27 11:35 app-cdr

0 drwxr-xr-x  135 portage portage  2343 iul 27 11:35 app-crypt

0 drwxr-xr-x  331 portage portage  6909 iul 27 11:35 app-dicts

0 drwxr-xr-x   46 portage portage   914 iul 27 11:35 app-doc

0 drwxr-xr-x   92 portage portage  1298 iul 27 11:35 app-editors

0 drwxr-xr-x  198 portage portage  3340 iul 27 11:35 app-emacs

0 drwxr-xr-x  100 portage portage  1908 iul 27 11:35 app-emulation

0 drwxr-xr-x   51 portage portage  1178 iul 27 11:35 app-eselect

0 drwxr-xr-x   30 portage portage   458 iul 27 11:35 app-forensics

0 drwxr-xr-x  132 portage portage  2415 aug  7 19:18 app-i18n

0 drwxr-xr-x   23 portage portage   400 aug  9  2015 app-laptop

0 drwxr-xr-x   74 portage portage  1435 aug  9  2015 app-leechcraft

0 drwxr-xr-x  285 portage portage  4496 iul 28 09:38 app-misc

0 drwxr-xr-x   33 portage portage   529 aug  8 06:59 app-mobilephone

0 drwxr-xr-x   61 portage portage  1044 aug  4 15:51 app-office

0 drwxr-xr-x   10 portage portage   165 aug  9  2015 app-officeext

0 drwxr-xr-x   25 portage portage   433 iul 27 11:35 app-pda

0 drwxr-xr-x   56 portage portage   954 aug  4 15:51 app-portage

0 drwxr-xr-x   42 portage portage   655 iul 27 11:35 app-shells

0 drwxr-xr-x  324 portage portage  5249 iul 27 11:35 app-text

0 drwxr-xr-x  179 portage portage  3135 iul 29 07:30 app-vim

0 drwxr-xr-x  133 portage portage  2031 aug  9  2015 app-xemacs

0 drwxr-xr-x    7 portage portage   120 aug  9  2015 dev-ada

0 drwxr-xr-x   59 portage portage   973 iul 27 11:35 dev-cpp

0 drwxr-xr-x  126 portage portage  2353 aug  4 15:51 dev-db

0 drwxr-xr-x   52 portage portage  1042 iul 23 08:18 dev-dotnet

0 drwxr-xr-x   68 portage portage  1305 iul 27 11:35 dev-embedded

0 drwxr-xr-x   29 root    root      437 iun  8 09:00 dev-erlang

0 drwxr-xr-x   38 portage portage   605 iul 27 11:35 dev-games

0 drwxr-xr-x   29 portage portage   484 iul 29 23:33 dev-go

0 drwxr-xr-x  569 portage portage 10686 aug  4 15:51 dev-haskell

0 drwxr-xr-x  595 portage portage 11149 aug  4 15:51 dev-java

0 drwxr-xr-x  117 portage portage  1714 iul 29 07:30 dev-lang

0 drwxr-xr-x  506 portage portage  8309 aug  5 12:39 dev-libs

0 drwxr-xr-x   21 portage portage   374 iul 27 11:35 dev-lisp

0 drwxr-xr-x   35 portage portage   558 iul 13 14:55 dev-lua

0 drwxr-xr-x  170 portage portage  2934 iul 27 11:35 dev-ml

0 drwxr-xr-x 1421 portage portage 30758 aug  4 15:51 dev-perl

0 drwxr-xr-x  245 portage portage  5395 aug  6 10:13 dev-php

0 drwxr-xr-x 1522 portage portage 27528 aug  8 06:59 dev-python

0 drwxr-xr-x   58 portage portage  1044 aug  1 12:27 dev-qt

0 drwxr-xr-x  321 portage portage  6943 iul 27 11:35 dev-ros

0 drwxr-xr-x  619 portage portage 11097 aug  8 06:59 dev-ruby

0 drwxr-xr-x   37 portage portage   604 iul 27 11:35 dev-scheme

0 drwxr-xr-x   43 portage portage   625 aug  9  2015 dev-tcltk

0 drwxr-xr-x   88 portage portage  1406 iul 27 11:35 dev-tex

0 drwxr-xr-x   88 portage portage  2574 aug  9  2015 dev-texlive

0 drwxr-xr-x  360 portage portage  6276 aug  8 06:59 dev-util

0 drwxr-xr-x   91 portage portage  1467 iul 13 14:55 dev-vcs

0 drwxr-xr-x    4 portage portage  5763 aug  8 06:59 eclass

0 drwxr-xr-x   82 portage portage  1500 iul 27 11:35 games-action

0 drwxr-xr-x  137 portage portage  2378 iul 27 11:35 games-arcade

0 drwxr-xr-x   79 portage portage  1272 iul 27 11:35 games-board

0 drwxr-xr-x   63 portage portage  1057 iul 27 11:35 games-emulation

0 drwxr-xr-x   21 portage portage   325 aug  9  2015 games-engines

0 drwxr-xr-x  130 portage portage  2722 apr 28 10:41 games-fps

0 drwxr-xr-x   13 portage portage   233 iul 19 10:06 games-kids

0 drwxr-xr-x   80 portage portage  1836 iul 19 10:06 games-misc

0 drwxr-xr-x   16 portage portage   238 aug  9  2015 games-mud

0 drwxr-xr-x  112 portage portage  1870 iul 27 11:35 games-puzzle

0 drwxr-xr-x   20 portage portage   316 iul 27 11:35 games-roguelike

0 drwxr-xr-x   58 portage portage  1086 mai 20 18:40 games-rpg

0 drwxr-xr-x   13 portage portage   226 iul 27 11:35 games-server

0 drwxr-xr-x   20 portage portage   359 iul 27 11:35 games-simulation

0 drwxr-xr-x   17 portage portage   277 iul 27 11:35 games-sports

0 drwxr-xr-x   58 portage portage   997 iul 27 11:35 games-strategy

0 drwxr-xr-x   41 portage portage   636 iul 27 11:35 games-util

0 drwxr-xr-x   37 portage portage   735 iul 30 19:01 gnome-base

0 drwxr-xr-x   79 portage portage  1826 iul 30 19:01 gnome-extra

0 drwxr-xr-x   40 portage portage   664 iul 21 13:26 gnustep-apps

0 drwxr-xr-x   11 portage portage   236 iul 21 13:26 gnustep-base

0 drwxr-xr-x   16 portage portage   273 aug  9  2015 gnustep-libs

1 -rw-r--r--    1 portage portage   115 ian  1  2016 header.txt

0 drwxr-xr-x   15 portage portage   256 aug  9  2015 java-virtuals

0 drwxr-xr-x  275 portage portage  5142 aug  7 19:18 kde-apps

0 drwxr-xr-x   45 portage portage   860 aug  7 19:18 kde-base

0 drwxr-xr-x   75 portage portage  1341 iul 28 09:38 kde-frameworks

0 drwxr-xr-x  110 portage portage  2150 aug  7 19:18 kde-misc

0 drwxr-xr-x   44 portage portage   879 iul 28 09:38 kde-plasma

0 drwxr-xr-x    2 portage portage 12796 aug  4 15:51 licenses

0 drwxr-xr-x    6 portage portage   233 aug  4 16:24 local

0 drwxr-xr-x   19 portage portage   354 iun 27 09:06 lxde-base

0 drwxr-xr-x   19 portage portage   381 iul 26 07:27 lxqt-base

0 drwxr-xr-x   28 portage portage   465 iul 29 07:30 mail-client

0 drwxr-xr-x   69 portage portage  1214 iul 30 19:01 mail-filter

0 drwxr-xr-x   15 portage portage   246 iul 21 13:26 mail-mta

0 drwxr-xr-x   14 portage portage   280 iul 26 07:27 mate-base

0 drwxr-xr-x   16 portage portage   346 aug  7 19:18 mate-extra

0 drwxr-xr-x  208 portage portage  4248 iul 27 11:35 media-fonts

0 drwxr-xr-x  266 portage portage  4456 iul 27 11:35 media-gfx

0 drwxr-xr-x  399 portage portage  6634 iul 27 11:35 media-libs

0 drwxr-xr-x  278 portage portage  6139 aug  7 19:18 media-plugins

0 drwxr-xr-x   25 portage portage   368 iul 27 11:35 media-radio

0 drwxr-xr-x  401 portage portage  6529 iul 27 11:35 media-sound

0 drwxr-xr-x   24 portage portage   426 iul 27 11:35 media-tv

0 drwxr-xr-x  186 portage portage  3219 aug  4 15:51 media-video

0 drwxr-xr-x    8 portage portage   272 aug  9 07:24 metadata

0 drwxr-xr-x  295 portage portage  4961 aug  5 12:39 net-analyzer

0 drwxr-xr-x   54 portage portage   910 iul 27 11:35 net-dialup

0 drwxr-xr-x   58 portage portage  1010 iul 27 11:35 net-dns

0 drwxr-xr-x   36 portage portage   610 iul 27 11:35 net-firewall

0 drwxr-xr-x   22 portage portage   370 iul 27 11:35 net-fs

0 drwxr-xr-x   31 portage portage   471 iul 28 09:38 net-ftp

0 drwxr-xr-x   54 portage portage   921 iul 29 07:30 net-im

0 drwxr-xr-x   63 portage portage   979 iul 29 07:30 net-irc

0 drwxr-xr-x  205 portage portage  3607 iul 27 11:35 net-libs

0 drwxr-xr-x  111 portage portage  1898 iul 27 11:35 net-mail

0 drwxr-xr-x  407 portage portage  6760 aug  4 15:51 net-misc

0 drwxr-xr-x   25 portage portage   438 iul 27 11:35 net-nds

0 drwxr-xr-x   16 portage portage   274 aug  9  2015 net-news

0 drwxr-xr-x   19 portage portage   254 iul 27 11:35 net-nntp

0 drwxr-xr-x   65 portage portage  1152 aug  8 06:59 net-p2p

0 drwxr-xr-x   42 portage portage   765 iul 27 11:35 net-print

0 drwxr-xr-x   39 portage portage   645 iul 27 11:35 net-proxy

0 drwxr-xr-x   14 portage portage   254 aug  9  2015 net-voip

0 drwxr-xr-x   78 portage portage  1333 iul 29 07:30 net-wireless

0 drwx------    3 root    root       61 aug  8 23:15 packages

0 drwxr-xr-x   48 portage portage   952 iul 17 09:01 perl-core

0 drwxr-xr-x   14 portage portage   682 aug  9 07:25 profiles

0 drwxr-xr-x   52 portage portage  1049 iul 27 11:35 ros-meta

0 drwxr-xr-x   40 portage portage   633 iun  8 09:00 sci-astronomy

0 drwxr-xr-x  149 portage portage  2420 iul 27 11:35 sci-biology

0 drwxr-xr-x   23 portage portage   382 aug  9  2015 sci-calculators

0 drwxr-xr-x  114 portage portage  1879 iul 27 11:35 sci-chemistry

0 drwxr-xr-x   56 portage portage   869 iul 27 11:35 sci-electronics

0 drwxr-xr-x   66 portage portage  1346 iul 27 11:35 sci-geosciences

0 drwxr-xr-x  240 portage portage  3817 iul 27 11:35 sci-libs

0 drwxr-xr-x   88 portage portage  1307 iul 27 11:35 sci-mathematics

0 drwxr-xr-x   21 portage portage   348 iul 27 11:35 sci-misc

0 drwxr-xr-x   36 portage portage   555 iul 28 09:38 sci-physics

0 drwxr-xr-x   36 portage portage   545 iul 27 11:35 sci-visualization

0 drwxr-xr-x    2 portage portage    35 aug  9  2015 scripts

0 drwxr-xr-x  258 portage portage  5883 iul 28 09:38 sec-policy

8 -rw-r--r--    1 portage portage  7328 ian 27  2016 skel.ebuild

2 -rw-r--r--    1 portage portage  1181 feb  1  2016 skel.metadata.xml

0 drwxr-xr-x  269 portage portage  4616 iul 27 11:35 sys-apps

0 drwxr-xr-x   66 portage portage  1213 iul 27 11:35 sys-auth

0 drwxr-xr-x   65 portage portage  1053 iul 27 11:35 sys-block

0 drwxr-xr-x   44 portage portage   751 iul 27 11:35 sys-boot

0 drwxr-xr-x   80 portage portage  1276 iul 14 08:15 sys-cluster

0 drwxr-xr-x   52 portage portage   855 iul 13 14:55 sys-devel

0 drwxr-xr-x   29 root    root      481 iun 30 07:27 sys-fabric

0 drwxr-xr-x   31 portage portage   676 iul 27 11:35 sys-firmware

0 drwxr-xr-x   19 portage portage   399 iul 27 11:35 sys-freebsd

0 drwxr-xr-x  136 portage portage  2250 iul 27 11:35 sys-fs

0 drwxr-xr-x   27 portage portage   547 iul 27 11:35 sys-kernel

0 drwxr-xr-x   87 portage portage  1465 aug  4 15:51 sys-libs

0 drwxr-xr-x   35 portage portage   591 iul 27 11:35 sys-power

0 drwxr-xr-x   51 portage portage   795 iul 27 11:35 sys-process

0 drwxr-xr-x  202 portage portage  4216 iul 13 14:55 virtual

0 drwxr-xr-x   72 portage portage  1455 iul 27 11:35 www-apache

0 drwxr-xr-x  102 portage portage  1825 aug  5 12:39 www-apps

0 drwxr-xr-x   49 portage portage   785 iul 27 11:35 www-client

0 drwxr-xr-x   23 portage portage   397 iul 27 11:35 www-misc

0 drwxr-xr-x   14 portage portage   310 iul 28 09:38 www-plugins

0 drwxr-xr-x   32 portage portage   480 iul 27 11:35 www-servers

0 drwxr-xr-x   95 portage portage  1470 iul 27 11:35 x11-apps

0 drwxr-xr-x    5 portage portage    90 iul 22 16:01 x11-base

0 drwxr-xr-x   74 portage portage  1834 iul 29 07:30 x11-drivers

0 drwxr-xr-x  148 portage portage  2630 iul 27 11:35 x11-libs

0 drwxr-xr-x  305 portage portage  4992 iul 27 11:35 x11-misc

0 drwxr-xr-x  194 portage portage  3489 iul 27 11:35 x11-plugins

0 drwxr-xr-x   36 portage portage   692 aug  9  2015 x11-proto

0 drwxr-xr-x   31 portage portage   500 iul 30 19:01 x11-terms

0 drwxr-xr-x  138 portage portage  3198 iul 27 11:35 x11-themes

0 drwxr-xr-x   58 portage portage   854 iul 27 11:35 x11-wm

0 drwxr-xr-x   16 portage portage   278 aug  9  2015 xfce-base

0 drwxr-xr-x   68 portage portage  1804 iul 29 23:33 xfce-extra

```

----------

## mv

 *costel78 wrote:*   

> overlay/squashfs

 

This output suggest that the changes of squashmount-15.0 should not take any effect. (Of course, there can always be strange bugs, but I would be surprised, because I cannot reproduce it here). You can try to reemerge an older version to verifytis (just copy the ebuild).

 *Quote:*   

> CHMOD_DIR: unchanged
> 
> CHOWN_DIR: unchanged

 

This output suggests that squashmount does not fiddle with any permissions (unless there is a strange bug in code which has not been touched since many versions).

So everything hints that this is a problem in the overlay code of the kernel.

As mentioned, I had similar issues also in certain special circumstances. Try whether you can remove manually e.g. app-text/XML-Schema-learner/XML-Schema-learner-1.0.0.ebuild and if not (what I consider likely) how the coresponding file (or its parent(s) if it does not exist) looks like in the corresponding CHANGES and READONLY directory; I would guess that this file or some of its parents are character devices. Just to be sure, check that the filesystem on which /usr/portage.mount resides does support xattr (which is required by overlay to function properly).

As a quick "solution", probably 

```
emerge --kill --force remount portage
```

 will perhaps solve your problem. This command, however, will have the side effect that all the latest changes are lost and perhaps that also the problem is no longer reproducible for the case that you want to report it upstream to overlay. However, the latter will be hard anyway, since it is perhaps not clear how to reproduce it...

----------

## costel78

After many attempts I think I figured it out. Keeping a overlay in /srv/copy was not a good ideea.

I restored the original sqashmount.pl and tried with minimal changes - no luck.

When I removed the 3 routines at the end of my config, everything started to work. (after_mount, before_umount, before_mount)

Log:

```
gentoo costel # cat squashmount.log

Step 1

Restore /usr/portage and /var/db from backup

Remove /usr/portage.mount and /var/db.mount

Manually start squashmount:

gentoo ~ # squashmount -vvv start 

 * squashmount: reading config file /etc/squashmount.pl

 * [db]:      It seems this is mounted for the first time:

              The squash-file /var/db.mount/db.sfs does not exist yet;

              it will be initialized now from /var/db

/usr/bin/mksquashfs /var/db /var/db.mount/db.sfs -noappend -quiet -comp lz4 -Xhc

[=================================================================================================================/] 39787/39787 100%

/sbin/modprobe squashfs

/sbin/modprobe loop

/bin/mount -t squashfs -o loop,ro,noatime -- /var/db.mount/db.sfs /tmp/xls1RfVeR4

/usr/bin/lsof -- /tmp/xls1RfVeR4

/bin/umount -- /tmp/xls1RfVeR4

 * [db]:      cleaning original DIR

 * [db]:      cleaning /var/db

 * [db]:      mounting...

/bin/mount -t squashfs -o loop,ro,noatime -- /var/db.mount/db.sfs /var/db.mount/readonly

/sbin/modprobe overlay

/bin/mount -t overlay -o noatime -o upperdir=/var/db.mount/changes -o lowerdir=/var/db.mount/readonly -o workdir=/var/db.mount/workdir -- overlay /var/db

 * [portage]: It seems this is mounted for the first time:

              The squash-file /usr/portage.mount/db.sfs does not exist yet;

              it will be initialized now from /usr/portage

/usr/bin/mksquashfs /usr/portage /usr/portage.mount/db.sfs -noappend -quiet -comp lz4 -Xhc

[===============================================================================================================|] 179514/179514 100%

/bin/mount -t squashfs -o loop,ro,noatime -- /usr/portage.mount/db.sfs /tmp/Y3cHBM8qqk

/usr/bin/lsof -- /tmp/Y3cHBM8qqk

/bin/umount -- /tmp/Y3cHBM8qqk

 * [portage]: cleaning original DIR

 * [portage]: cleaning /usr/portage

 * [portage]: mounting...

/bin/mount -t squashfs -o loop,ro,noatime -- /usr/portage.mount/db.sfs /usr/portage.mount/readonly

/bin/mount -t overlay -o noatime -o upperdir=/usr/portage.mount/changes -o lowerdir=/usr/portage.mount/readonly -o workdir=/usr/portage.mount/workdir -- overlay /usr/portage

Step 2

Manual test:

gentoo ~ # cd /usr/portage

gentoo portage # touch test.ebuild

gentoo portage # echo "asdf" > test.ebuild

gentoo portage # cat test.ebuild 

asdf

gentoo portage # rm test.ebuild 

Try to rsync:

gentoo portage # emerge --sync

>>> Syncing repository 'gentoo' into '/usr/portage'...

>>> Starting rsync with rsync://176.28.50.119/gentoo-portage...

Welcome to quetzal.gentoo.org / rsync.gentoo.org

Server Address : 2a01:488:67:1000:b01c:3277:0:1

Contact Name   : mirror-admin@gentoo.org

Hardware       : 4 x Intel(R) Xeon(R) CPU E5649 @ 2.53GHz, 16073MB RAM

Sponsor        : Host Europe, Cologne, Germany, EU

Please note: common gentoo-netiquette says you should not sync more

than once a day.  Users who abuse the rsync.gentoo.org rotation

may be added to a temporary ban list.

MOTD autogenerated by update-rsync-motd on Wed Dec 16 19:33:43 UTC 2015

receiving file list ... 

1 file to consider

timestamp.chk

             32 100%   31.25kB/s    0:00:00 (xfr#1, to-chk=0/1)

Number of files: 1 (reg: 1)

Number of created files: 0

Number of deleted files: 0

Number of regular files transferred: 1

Total file size: 32 bytes

Total transferred file size: 32 bytes

Literal data: 32 bytes

Matched data: 0 bytes

File list size: 39

File list generation time: 0.001 seconds

File list transfer time: 0.000 seconds

Total bytes sent: 100

Total bytes received: 126

sent 100 bytes  received 126 bytes  150.67 bytes/sec

total size is 32  speedup is 0.14

Welcome to quetzal.gentoo.org / rsync.gentoo.org

Server Address : 2a01:488:67:1000:b01c:3277:0:1

Contact Name   : mirror-admin@gentoo.org

Hardware       : 4 x Intel(R) Xeon(R) CPU E5649 @ 2.53GHz, 16073MB RAM

Sponsor        : Host Europe, Cologne, Germany, EU

Please note: common gentoo-netiquette says you should not sync more

than once a day.  Users who abuse the rsync.gentoo.org rotation

may be added to a temporary ban list.

MOTD autogenerated by update-rsync-motd on Wed Dec 16 19:33:43 UTC 2015

receiving file list ... 

204630 files to consider

deleting app-i18n/man-pages-de/man-pages-de-1.12.ebuild

deleting app-text/XML-Schema-learner/XML-Schema-learner-1.0.0.ebuild

deleting dev-db/aerospike-server-community/aerospike-server-community-3.9.0.ebuild

deleting dev-db/aerospike-server-community/aerospike-server-community-3.8.2.2.ebuild

deleting dev-db/aerospike-server-community/aerospike-server-community-3.8.1.ebuild

deleting dev-db/aerospike-server-community/aerospike-server-community-3.8.1.2.ebuild

deleting dev-lang/coffee-script/coffee-script-1.10.0.ebuild

deleting dev-ruby/multi_json/multi_json-1.12.0.ebuild

deleting dev-ruby/multi_json/multi_json-1.11.3.ebuild

deleting kde-apps/kgamma/files/kgamma-4.14.3-cmake34.patch

deleting kde-apps/kgamma/files/

deleting kde-apps/kgamma/metadata.xml

deleting kde-apps/kgamma/kgamma-4.14.3.ebuild

deleting kde-apps/kgamma/Manifest

deleting kde-apps/kgamma/ChangeLog-2015

deleting kde-apps/kgamma/ChangeLog

deleting kde-apps/kgamma/

deleting mail-filter/pypolicyd-spf/pypolicyd-spf-1.3.1.ebuild

deleting mail-filter/pypolicyd-spf/pypolicyd-spf-1.1.ebuild

deleting metadata/md5-cache/app-i18n/man-pages-de-1.12

deleting metadata/md5-cache/app-text/XML-Schema-learner-1.0.0

deleting metadata/md5-cache/dev-db/aerospike-server-community-3.9.0

deleting metadata/md5-cache/dev-db/aerospike-server-community-3.8.2.2

deleting metadata/md5-cache/dev-db/aerospike-server-community-3.8.1.2

deleting metadata/md5-cache/dev-db/aerospike-server-community-3.8.1

deleting metadata/md5-cache/dev-lang/coffee-script-1.10.0

deleting metadata/md5-cache/dev-ruby/multi_json-1.12.0

deleting metadata/md5-cache/dev-ruby/multi_json-1.11.3

deleting metadata/md5-cache/kde-apps/kgamma-4.14.3

deleting metadata/md5-cache/mail-filter/pypolicyd-spf-1.3.1

deleting metadata/md5-cache/mail-filter/pypolicyd-spf-1.1

deleting metadata/md5-cache/net-analyzer/nagios-check_mysql_health-2.1.8.2

deleting metadata/md5-cache/net-analyzer/monitoring-plugins-2.1.1

deleting metadata/md5-cache/net-mail/postfix-logwatch-1.40.00

deleting metadata/md5-cache/sci-mathematics/octave-4.0.2-r1

deleting metadata/md5-cache/sci-mathematics/octave-3.8.2

deleting net-analyzer/monitoring-plugins/monitoring-plugins-2.1.1.ebuild

deleting net-analyzer/nagios-check_mysql_health/nagios-check_mysql_health-2.1.8.2.ebuild

deleting net-mail/postfix-logwatch/postfix-logwatch-1.40.00.ebuild

deleting sci-mathematics/octave/octave-4.0.2-r1.ebuild

deleting sci-mathematics/octave/octave-3.8.2.ebuild

app-admin/aerospike-amc-community/Manifest

          4.21K 100%    4.11MB/s    0:00:00 (xfr#1, to-chk=204261/204630)

app-admin/aerospike-amc-community/aerospike-amc-community-3.6.10.1.ebuild

          1.38K 100%    1.34MB/s    0:00:00 (xfr#2, to-chk=204260/204630)

app-i18n/man-pages-de/ChangeLog

          4.91K 100%   80.53kB/s    0:00:00 (xfr#3, to-chk=191268/204630)

app-i18n/man-pages-de/Manifest

          2.96K 100%   48.48kB/s    0:00:00 (xfr#4, to-chk=191266/204630)

app-i18n/man-pages-de/man-pages-de-1.13.ebuild

          1.26K 100%   20.72kB/s    0:00:00 (xfr#5, to-chk=191265/204630)

app-i18n/man-pages-de/man-pages-de-1.14.ebuild

          1.28K 100%   20.92kB/s    0:00:00 (xfr#6, to-chk=191264/204630)

app-misc/elasticsearch/Manifest

         13.84K 100%  114.39kB/s    0:00:00 (xfr#7, to-chk=189306/204630)

app-misc/elasticsearch/elasticsearch-2.3.5.ebuild

          2.01K 100%   16.63kB/s    0:00:00 (xfr#8, to-chk=189294/204630)

app-misc/elasticsearch/files/elasticsearch.sysctl.d

             24 100%    0.19kB/s    0:00:00 (xfr#9, to-chk=189283/204630)

app-misc/elasticsearch/files/elasticsearch.tmpfiles.d

             67 100%    0.54kB/s    0:00:00 (xfr#10, to-chk=189282/204630)

app-text/XML-Schema-learner/ChangeLog

          2.37K 100%   12.88kB/s    0:00:00 (xfr#11, to-chk=185544/204630)

app-text/XML-Schema-learner/Manifest

          1.84K 100%   10.02kB/s    0:00:00 (xfr#12, to-chk=185542/204630)

dev-db/aerospike-server-community/Manifest

          7.25K 100%   39.17kB/s    0:00:00 (xfr#13, to-chk=180302/204630)

dev-db/aerospike-server-community/aerospike-server-community-3.9.0.3.ebuild

          1.56K 100%    8.40kB/s    0:00:00 (xfr#14, to-chk=180297/204630)

dev-lang/coffee-script/ChangeLog

          2.97K 100%   15.97kB/s    0:00:00 (xfr#15, to-chk=168913/204630)

dev-lang/coffee-script/Manifest

          2.60K 100%   13.89kB/s    0:00:00 (xfr#16, to-chk=168911/204630)

dev-lang/coffee-script/coffee-script-1.10.0-r1.ebuild

          1.10K 100%    5.90kB/s    0:00:00 (xfr#17, to-chk=168910/204630)

dev-python/elasticsearch-curator/Manifest

          4.15K 100%   22.17kB/s    0:00:00 (xfr#18, to-chk=148233/204630)

dev-python/elasticsearch-curator/elasticsearch-curator-4.0.5.ebuild

          2.92K 100%   10.87kB/s    0:00:00 (xfr#19, to-chk=148230/204630)

dev-python/gmpy/Manifest

          4.02K 100%   14.94kB/s    0:00:00 (xfr#20, to-chk=147345/204630)

dev-python/gmpy/gmpy-2.0.8.ebuild

          1.43K 100%    5.29kB/s    0:00:00 (xfr#21, to-chk=147341/204630)

dev-ruby/httpclient/ChangeLog

          5.26K 100%   19.49kB/s    0:00:00 (xfr#22, to-chk=134183/204630)

dev-ruby/httpclient/Manifest

          4.81K 100%   17.75kB/s    0:00:00 (xfr#23, to-chk=134181/204630)

dev-ruby/httpclient/httpclient-2.8.1.ebuild

          1.72K 100%    6.34kB/s    0:00:00 (xfr#24, to-chk=134176/204630)

dev-ruby/multi_json/ChangeLog

          4.59K 100%   16.82kB/s    0:00:00 (xfr#25, to-chk=133625/204630)

dev-ruby/multi_json/Manifest

          4.08K 100%   14.93kB/s    0:00:00 (xfr#26, to-chk=133623/204630)

dev-ruby/multi_json/multi_json-1.11.2.ebuild

          1.88K 100%    6.89kB/s    0:00:00 (xfr#27, to-chk=133621/204630)

dev-ruby/multi_json/multi_json-1.12.1.ebuild

          1.87K 100%    6.81kB/s    0:00:00 (xfr#28, to-chk=133620/204630)

dev-ruby/multi_json/multi_json-1.9.3.ebuild

          1.83K 100%    6.67kB/s    0:00:00 (xfr#29, to-chk=133619/204630)

dev-ruby/rspec-retry/ChangeLog

          1.22K 100%    4.42kB/s    0:00:00 (xfr#30, to-chk=132575/204630)

dev-ruby/rspec-retry/Manifest

          2.21K 100%    8.00kB/s    0:00:00 (xfr#31, to-chk=132574/204630)

dev-ruby/rspec-retry/rspec-retry-0.5.0.ebuild

            664 100%    2.35kB/s    0:00:00 (xfr#32, to-chk=132571/204630)

dev-ruby/syntax/ChangeLog

          5.00K 100%   14.15kB/s    0:00:00 (xfr#33, to-chk=131666/204630)

dev-ruby/syntax/Manifest

          2.94K 100%    8.28kB/s    0:00:00 (xfr#34, to-chk=131664/204630)

dev-ruby/syntax/syntax-1.2.1.ebuild

            911 100%    2.51kB/s    0:00:00 (xfr#35, to-chk=131661/204630)

dev-util/jenkins-bin/ChangeLog

         14.70K 100%   41.29kB/s    0:00:00 (xfr#36, to-chk=127562/204630)

dev-util/jenkins-bin/Manifest

          5.54K 100%   15.52kB/s    0:00:00 (xfr#37, to-chk=127560/204630)

dev-util/jenkins-bin/jenkins-bin-2.11.ebuild

          1.08K 100%    3.04kB/s    0:00:00 (xfr#38, to-chk=127558/204630)

dev-util/jenkins-bin/jenkins-bin-2.12.ebuild

          1.09K 100%    3.04kB/s    0:00:00 (xfr#39, to-chk=127557/204630)

mail-filter/pypolicyd-spf/ChangeLog

          4.85K 100%   13.54kB/s    0:00:00 (xfr#40, to-chk=110511/204630)

mail-filter/pypolicyd-spf/Manifest

          1.84K 100%    5.13kB/s    0:00:00 (xfr#41, to-chk=110509/204630)

media-libs/libsfml/ChangeLog

          4.42K 100%   12.34kB/s    0:00:00 (xfr#42, to-chk=103822/204630)

media-libs/libsfml/Manifest

          2.95K 100%    8.16kB/s    0:00:00 (xfr#43, to-chk=103820/204630)

media-libs/libsfml/libsfml-2.4.0.ebuild

          1.44K 100%    3.99kB/s    0:00:00 (xfr#44, to-chk=103818/204630)

metadata/layout.conf

          1.42K 100%    3.94kB/s    0:00:00 (xfr#45, to-chk=94405/204630)

metadata/timestamp

             29 100%    0.08kB/s    0:00:00 (xfr#46, to-chk=94403/204630)

metadata/timestamp.chk

             32 100%    0.09kB/s    0:00:00 (xfr#47, to-chk=94402/204630)

metadata/timestamp.x

             43 100%    0.12kB/s    0:00:00 (xfr#48, to-chk=94401/204630)

metadata/dtd/timestamp.chk

             32 100%    0.09kB/s    0:00:00 (xfr#49, to-chk=94387/204630)

metadata/glsa/timestamp.chk

             32 100%    0.09kB/s    0:00:00 (xfr#50, to-chk=92148/204630)

metadata/md5-cache/app-admin/aerospike-amc-community-3.6.10.1

            783 100%    2.11kB/s    0:00:00 (xfr#51, to-chk=92083/204630)

metadata/md5-cache/app-i18n/man-pages-de-1.13

            782 100%    2.10kB/s    0:00:00 (xfr#52, to-chk=89242/204630)

metadata/md5-cache/app-i18n/man-pages-de-1.14

            795 100%    2.14kB/s    0:00:00 (xfr#53, to-chk=89241/204630)

metadata/md5-cache/app-misc/elasticsearch-2.3.5

            713 100%    1.92kB/s    0:00:00 (xfr#54, to-chk=88710/204630)

metadata/md5-cache/dev-db/aerospike-server-community-3.9.0.3

            562 100%    1.51kB/s    0:00:00 (xfr#55, to-chk=86705/204630)

metadata/md5-cache/dev-lang/coffee-script-1.10.0-r1

            348 100%    0.94kB/s    0:00:00 (xfr#56, to-chk=84011/204630)

metadata/md5-cache/dev-python/elasticsearch-curator-4.0.5

          5.63K 100%   12.94kB/s    0:00:00 (xfr#57, to-chk=79212/204630)

metadata/md5-cache/dev-python/gmpy-2.0.8

          2.46K 100%    5.63kB/s    0:00:00 (xfr#58, to-chk=78943/204630)

metadata/md5-cache/dev-ruby/httpclient-2.8.1

          3.94K 100%    8.99kB/s    0:00:00 (xfr#59, to-chk=74557/204630)

metadata/md5-cache/dev-ruby/multi_json-1.11.2

          3.63K 100%    8.28kB/s    0:00:00 (xfr#60, to-chk=74402/204630)

metadata/md5-cache/dev-ruby/multi_json-1.12.1

          4.49K 100%   10.26kB/s    0:00:00 (xfr#61, to-chk=74401/204630)

metadata/md5-cache/dev-ruby/multi_json-1.9.3

          2.78K 100%    6.33kB/s    0:00:00 (xfr#62, to-chk=74400/204630)

metadata/md5-cache/dev-ruby/rspec-retry-0.5.0

          3.20K 100%    7.28kB/s    0:00:00 (xfr#63, to-chk=74096/204630)

metadata/md5-cache/dev-ruby/syntax-1.2.1

          2.98K 100%    6.79kB/s    0:00:00 (xfr#64, to-chk=73784/204630)

metadata/md5-cache/dev-util/jenkins-bin-2.11

            611 100%    1.36kB/s    0:00:00 (xfr#65, to-chk=72765/204630)

metadata/md5-cache/dev-util/jenkins-bin-2.12

            613 100%    1.36kB/s    0:00:00 (xfr#66, to-chk=72764/204630)

metadata/md5-cache/media-libs/libsfml-2.4.0

          1.23K 100%    2.80kB/s    0:00:00 (xfr#67, to-chk=68074/204630)

metadata/md5-cache/net-analyzer/nagios-check_mysql_health-2.2.2

            452 100%    1.00kB/s    0:00:00 (xfr#68, to-chk=65834/204630)

metadata/md5-cache/net-analyzer/netperf-2.7.0-r1

            582 100%    1.29kB/s    0:00:00 (xfr#69, to-chk=65780/204630)

metadata/md5-cache/net-im/telegram-desktop-bin-0.10.1

            960 100%    2.13kB/s    0:00:00 (xfr#70, to-chk=65097/204630)

metadata/md5-cache/net-libs/gnutls-3.5.3

          4.69K 100%   10.64kB/s    0:00:00 (xfr#71, to-chk=64907/204630)

metadata/md5-cache/net-libs/nodejs-6.3.1

          2.18K 100%    4.95kB/s    0:00:00 (xfr#72, to-chk=64610/204630)

metadata/md5-cache/net-misc/tor-0.2.9.1_alpha

          1.42K 100%    3.20kB/s    0:00:00 (xfr#73, to-chk=63627/204630)

metadata/md5-cache/sci-mathematics/octave-3.6.4

          2.60K 100%    5.88kB/s    0:00:00 (xfr#74, to-chk=61400/204630)

metadata/md5-cache/sci-mathematics/octave-3.6.4-r1

          2.63K 100%    5.93kB/s    0:00:00 (xfr#75, to-chk=61399/204630)

metadata/md5-cache/sci-mathematics/octave-3.8.2-r1

          3.33K 100%    7.50kB/s    0:00:00 (xfr#76, to-chk=61398/204630)

metadata/md5-cache/sci-mathematics/octave-4.0.0

          3.55K 100%    7.98kB/s    0:00:00 (xfr#77, to-chk=61397/204630)

metadata/md5-cache/sci-mathematics/octave-4.0.0-r1

          3.55K 100%    7.96kB/s    0:00:00 (xfr#78, to-chk=61396/204630)

metadata/md5-cache/sci-mathematics/octave-4.0.1

          3.55K 100%    6.90kB/s    0:00:00 (xfr#79, to-chk=61395/204630)

metadata/md5-cache/sci-mathematics/octave-4.0.1-r1

          3.55K 100%    6.87kB/s    0:00:00 (xfr#80, to-chk=61394/204630)

metadata/md5-cache/sci-mathematics/octave-4.0.2-r2

          3.55K 100%    6.87kB/s    0:00:00 (xfr#81, to-chk=61393/204630)

metadata/md5-cache/sys-apps/diffutils-3.4

            895 100%    1.69kB/s    0:00:00 (xfr#82, to-chk=59491/204630)

metadata/md5-cache/sys-kernel/rt-sources-3.14.65_p68

          1.46K 100%    2.81kB/s    0:00:00 (xfr#83, to-chk=57425/204630)

metadata/md5-cache/sys-kernel/rt-sources-3.14.72_p75

          1.46K 100%    2.81kB/s    0:00:00 (xfr#84, to-chk=57424/204630)

metadata/md5-cache/sys-kernel/rt-sources-3.18.29_p30

          1.46K 100%    2.81kB/s    0:00:00 (xfr#85, to-chk=57423/204630)

metadata/md5-cache/sys-kernel/rt-sources-3.18.36_p37

          1.46K 100%    2.81kB/s    0:00:00 (xfr#86, to-chk=57422/204630)

metadata/md5-cache/sys-kernel/rt-sources-4.1.20_p23

          1.44K 100%    2.79kB/s    0:00:00 (xfr#87, to-chk=57421/204630)

metadata/md5-cache/sys-kernel/rt-sources-4.1.27_p30

          1.44K 100%    2.78kB/s    0:00:00 (xfr#88, to-chk=57420/204630)

metadata/md5-cache/sys-kernel/rt-sources-4.4.12_p19

          1.44K 100%    2.78kB/s    0:00:00 (xfr#89, to-chk=57419/204630)

metadata/md5-cache/sys-kernel/rt-sources-4.4.9_p17

          1.44K 100%    2.77kB/s    0:00:00 (xfr#90, to-chk=57418/204630)

metadata/md5-cache/sys-kernel/rt-sources-4.6.1_p3

          1.44K 100%    2.77kB/s    0:00:00 (xfr#91, to-chk=57417/204630)

metadata/md5-cache/sys-kernel/rt-sources-4.6.2_p5

          1.44K 100%    2.77kB/s    0:00:00 (xfr#92, to-chk=57416/204630)

metadata/md5-cache/sys-process/cronie-1.5.1

          1.05K 100%    2.02kB/s    0:00:00 (xfr#93, to-chk=57017/204630)

metadata/md5-cache/www-servers/nginx-1.11.3

          8.87K 100%   17.03kB/s    0:00:00 (xfr#94, to-chk=55986/204630)

metadata/news/timestamp.chk

             32 100%    0.06kB/s    0:00:00 (xfr#95, to-chk=53938/204630)

metadata/xml-schema/timestamp.chk

             32 100%    0.06kB/s    0:00:00 (xfr#96, to-chk=53682/204630)

net-analyzer/monitoring-plugins/ChangeLog

          4.30K 100%    8.24kB/s    0:00:00 (xfr#97, to-chk=52646/204630)

net-analyzer/monitoring-plugins/Manifest

          1.85K 100%    3.54kB/s    0:00:00 (xfr#98, to-chk=52644/204630)

net-analyzer/nagios-check_mysql_health/ChangeLog

          3.38K 100%    6.48kB/s    0:00:00 (xfr#99, to-chk=52525/204630)

net-analyzer/nagios-check_mysql_health/Manifest

          2.63K 100%    5.03kB/s    0:00:00 (xfr#100, to-chk=52523/204630)

net-analyzer/nagios-check_mysql_health/nagios-check_mysql_health-2.2.2.ebuild

          1.12K 100%    2.14kB/s    0:00:00 (xfr#101, to-chk=52520/204630)

net-analyzer/netperf/ChangeLog

          3.72K 100%    7.10kB/s    0:00:00 (xfr#102, to-chk=52200/204630)

net-analyzer/netperf/Manifest

          5.53K 100%   10.54kB/s    0:00:00 (xfr#103, to-chk=52198/204630)

net-analyzer/netperf/metadata.xml

            775 100%    1.44kB/s    0:00:00 (xfr#104, to-chk=52197/204630)

net-analyzer/netperf/netperf-2.7.0-r1.ebuild

          1.85K 100%    3.29kB/s    0:00:00 (xfr#105, to-chk=52195/204630)

net-analyzer/netperf/files/netperf-2.7.0-init

            440 100%    0.76kB/s    0:00:00 (xfr#106, to-chk=52188/204630)

net-analyzer/netperf/files/netperf-2.7.0-space.patch

            455 100%    0.79kB/s    0:00:00 (xfr#107, to-chk=52187/204630)

net-im/telegram-desktop-bin/ChangeLog

          1.52K 100%    2.71kB/s    0:00:00 (xfr#108, to-chk=48381/204630)

net-im/telegram-desktop-bin/Manifest

          5.24K 100%    8.75kB/s    0:00:00 (xfr#109, to-chk=48380/204630)

net-im/telegram-desktop-bin/telegram-desktop-bin-0.10.1.ebuild

          1.28K 100%    2.14kB/s    0:00:00 (xfr#110, to-chk=48377/204630)

net-libs/gnutls/Manifest

         13.95K 100%   23.22kB/s    0:00:00 (xfr#111, to-chk=47502/204630)

net-libs/gnutls/gnutls-3.5.3.ebuild

          3.77K 100%    6.26kB/s    0:00:00 (xfr#112, to-chk=47493/204630)

net-libs/nodejs/Manifest

         11.48K 100%   19.03kB/s    0:00:00 (xfr#113, to-chk=46341/204630)

net-libs/nodejs/nodejs-6.3.1.ebuild

          5.94K 100%    9.81kB/s    0:00:00 (xfr#114, to-chk=46327/204630)

net-mail/postfix-logwatch/ChangeLog

          2.38K 100%    3.94kB/s    0:00:00 (xfr#115, to-chk=45231/204630)

net-mail/postfix-logwatch/Manifest

          1.84K 100%    3.04kB/s    0:00:00 (xfr#116, to-chk=45229/204630)

net-mail/postfix-logwatch/metadata.xml

            304 100%    0.49kB/s    0:00:00 (xfr#117, to-chk=45228/204630)

net-misc/tor/ChangeLog

          8.25K 100%   13.58kB/s    0:00:00 (xfr#118, to-chk=41339/204630)

net-misc/tor/Manifest

          5.83K 100%    9.12kB/s    0:00:00 (xfr#119, to-chk=41337/204630)

net-misc/tor/tor-0.2.9.1_alpha.ebuild

          2.20K 100%    3.44kB/s    0:00:00 (xfr#120, to-chk=41333/204630)

profiles/use.local.desc

        676.28K 100%  386.67kB/s    0:00:01 (xfr#121, to-chk=37727/204630)

profiles/desc/nginx_modules_http.desc

          6.03K 100%    8.52kB/s    0:00:00 (xfr#122, to-chk=36516/204630)

profiles/desc/nginx_modules_stream.desc

          1.35K 100%    1.91kB/s    0:00:00 (xfr#123, to-chk=36514/204630)

profiles/updates/3Q-2016

            656 100%    0.90kB/s    0:00:00 (xfr#124, to-chk=35204/204630)

sci-mathematics/octave/ChangeLog

          7.25K 100%   10.16kB/s    0:00:00 (xfr#125, to-chk=28099/204630)

sci-mathematics/octave/Manifest

         12.00K 100%   16.69kB/s    0:00:00 (xfr#126, to-chk=28097/204630)

sci-mathematics/octave/octave-3.6.4-r1.ebuild

          3.40K 100%    4.72kB/s    0:00:00 (xfr#127, to-chk=28095/204630)

sci-mathematics/octave/octave-3.6.4.ebuild

          3.33K 100%    4.63kB/s    0:00:00 (xfr#128, to-chk=28094/204630)

sci-mathematics/octave/octave-3.8.2-r1.ebuild

          4.18K 100%    5.69kB/s    0:00:00 (xfr#129, to-chk=28093/204630)

sci-mathematics/octave/octave-4.0.0-r1.ebuild

          4.87K 100%    6.60kB/s    0:00:00 (xfr#130, to-chk=28092/204630)

sci-mathematics/octave/octave-4.0.0.ebuild

          4.55K 100%    6.17kB/s    0:00:00 (xfr#131, to-chk=28091/204630)

sci-mathematics/octave/octave-4.0.1-r1.ebuild

          4.70K 100%    6.23kB/s    0:00:00 (xfr#132, to-chk=28090/204630)

sci-mathematics/octave/octave-4.0.1.ebuild

          4.55K 100%    6.03kB/s    0:00:00 (xfr#133, to-chk=28089/204630)

sci-mathematics/octave/octave-4.0.2-r2.ebuild

          4.70K 100%    6.23kB/s    0:00:00 (xfr#134, to-chk=28088/204630)

sys-apps/diffutils/ChangeLog

          3.45K 100%    4.53kB/s    0:00:00 (xfr#135, to-chk=23588/204630)

sys-apps/diffutils/Manifest

          2.57K 100%    3.38kB/s    0:00:00 (xfr#136, to-chk=23586/204630)

sys-apps/diffutils/diffutils-3.4.ebuild

          1.25K 100%    1.64kB/s    0:00:00 (xfr#137, to-chk=23584/204630)

sys-kernel/rt-sources/ChangeLog

         11.16K 100%   14.57kB/s    0:00:00 (xfr#138, to-chk=15392/204630)

sys-kernel/rt-sources/Manifest

         17.80K 100%   22.64kB/s    0:00:00 (xfr#139, to-chk=15390/204630)

sys-kernel/rt-sources/rt-sources-3.14.65_p68.ebuild

          1.26K 100%    1.60kB/s    0:00:00 (xfr#140, to-chk=15388/204630)

sys-kernel/rt-sources/rt-sources-3.14.72_p75.ebuild

          1.26K 100%    1.58kB/s    0:00:00 (xfr#141, to-chk=15387/204630)

sys-kernel/rt-sources/rt-sources-3.18.29_p30.ebuild

          1.26K 100%    1.58kB/s    0:00:00 (xfr#142, to-chk=15386/204630)

sys-kernel/rt-sources/rt-sources-3.18.36_p37.ebuild

          1.26K 100%    1.58kB/s    0:00:00 (xfr#143, to-chk=15385/204630)

sys-kernel/rt-sources/rt-sources-4.1.20_p23.ebuild

          1.26K 100%    1.58kB/s    0:00:00 (xfr#144, to-chk=15384/204630)

sys-kernel/rt-sources/rt-sources-4.1.27_p30.ebuild

          1.26K 100%    1.58kB/s    0:00:00 (xfr#145, to-chk=15383/204630)

sys-kernel/rt-sources/rt-sources-4.4.12_p19.ebuild

          1.26K 100%    1.58kB/s    0:00:00 (xfr#146, to-chk=15382/204630)

sys-kernel/rt-sources/rt-sources-4.4.9_p17.ebuild

          1.26K 100%    1.57kB/s    0:00:00 (xfr#147, to-chk=15381/204630)

sys-kernel/rt-sources/rt-sources-4.6.1_p3.ebuild

          1.26K 100%    1.57kB/s    0:00:00 (xfr#148, to-chk=15380/204630)

sys-kernel/rt-sources/rt-sources-4.6.2_p5.ebuild

          1.26K 100%    1.57kB/s    0:00:00 (xfr#149, to-chk=15379/204630)

sys-process/cronie/ChangeLog

          4.35K 100%    5.39kB/s    0:00:00 (xfr#150, to-chk=13836/204630)

sys-process/cronie/Manifest

          4.76K 100%    5.90kB/s    0:00:00 (xfr#151, to-chk=13834/204630)

sys-process/cronie/cronie-1.5.1.ebuild

          2.08K 100%    2.57kB/s    0:00:00 (xfr#152, to-chk=13831/204630)

www-servers/nginx/ChangeLog

         14.01K 100%   17.17kB/s    0:00:00 (xfr#153, to-chk=9470/204630)

www-servers/nginx/Manifest

         14.70K 100%   17.60kB/s    0:00:00 (xfr#154, to-chk=9468/204630)

www-servers/nginx/nginx-1.11.3.ebuild

         28.14K 100%   32.64kB/s    0:00:00 (xfr#155, to-chk=9463/204630)

www-servers/nginx/files/nginx-1.11.3-fix-build-without-stream_ssl_module.patch

            873 100%    0.99kB/s    0:00:00 (xfr#156, to-chk=9460/204630)

Number of files: 204,630 (reg: 177,264, dir: 27,366)

Number of created files: 51 (reg: 51)

Number of deleted files: 41 (reg: 39, dir: 2)

Number of regular files transferred: 156

Total file size: 391.96M bytes

Total transferred file size: 1.16M bytes

Literal data: 1.16M bytes

Matched data: 0 bytes

File list size: 4.68M

File list generation time: 5.786 seconds

File list transfer time: 0.000 seconds

Total bytes sent: 3.08K

Total bytes received: 5.84M

sent 3.08K bytes  received 5.84M bytes  520.34K bytes/sec

total size is 391.96M  speedup is 67.07

=== Sync completed for gentoo

q: Updating ebuild cache in /usr/portage ... 

q: Finished 38041 entries in 0.101520 seconds

>>> Syncing repository 'mv' into '/usr/portage/local/mv'...

>>> Starting layman sync for mv...

 * Running Git... # ( cd /usr/portage/local/mv  && /usr/bin/git pull )

Already up-to-date.

 * 

 * Succeeded:

 * ------

 * Successfully synchronized overlay "mv".

 * 

>>> layman sync succeeded: mv

>>> laymansync sez... "Hasta la sync ya, baby!"

=== Sync completed for mv

q: Updating ebuild cache in /usr/portage/local/mv ... 

q: Finished 104 entries in 0.001474 seconds

Performing Global Updates

(Could take a couple of minutes if you have a lot of binary packages.)

  .='update pass'  *='binary update'  #='/var/db update'  @='/var/db move'

  s='/var/db SLOT move'  %='binary move'  S='binary SLOT move'

  p='update /etc/portage/package.*'

/usr/portage/profiles/updates/3Q-2016.............

gentoo portage # cd

gentoo ~ # /usr/bin/squashmount -f --lsof=0 --lsof-ro=0 stop -vvv

 * squashmount: reading config file /etc/squashmount.pl

 * [db]:      umounting...

/usr/bin/lsof -- /var/db

/bin/umount -- /var/db

 * [db]:      cleaning workdir...

 * [db]:      cleaning /var/db.mount/workdir

/usr/bin/lsof -- /var/db.mount/readonly

/bin/umount -- /var/db.mount/readonly

 * [db]:      cleaning changes...

 * [db]:      cleaning /var/db.mount/changes

 * [db]:      forgetting settings

 * [portage]: squashing (this may take a while)

/usr/bin/mksquashfs /usr/portage /tmp/EKxy53e79x -noappend -quiet -comp lz4 -Xhc

[===============================================================================================================/] 179526/179526 100%

 * [portage]: umounting...

/usr/bin/lsof -- /usr/portage

/bin/umount -- /usr/portage

 * [portage]: cleaning workdir...

 * [portage]: cleaning /usr/portage.mount/workdir

/usr/bin/lsof -- /usr/portage.mount/readonly

/bin/umount -- /usr/portage.mount/readonly

 * [portage]: tempfile (/tmp/EKxy53e79x) -> /usr/portage.mount/db.sfs

 * [portage]: cleaning changes...

 * [portage]: cleaning /usr/portage.mount/changes

 * [portage]: forgetting settings

 * [portage]: trying to remove directory /run/squashmount

 * [portage]: trying to remove directory /run

 * [portage]: did not remove directory

              Device or resource busy

Step 4:

Systemd service test:

gentoo ~ # ls /usr/portage

gentoo ~ # systemctl start squashmount

gentoo ~ # systemctl status squashmount

● squashmount.service - mount/umount all squashmount configured mount points

   Loaded: loaded (/usr/lib/systemd/system/squashmount.service; disabled; vendor preset: disabled)

  Drop-In: /etc/systemd/system/squashmount.service.d

           └─timeout.conf

   Active: active (exited) since Ma 2016-08-09 14:29:21 EEST; 5s ago

  Process: 27655 ExecStart=/usr/bin/squashmount start (code=exited, status=0/SUCCESS)

 Main PID: 27655 (code=exited, status=0/SUCCESS)

aug 09 14:29:21 gentoo systemd[1]: Starting mount/umount all squashmount configured mount points...

aug 09 14:29:21 gentoo squashmount[27655]:  * [db]:      mounting...

aug 09 14:29:21 gentoo squashmount[27655]:  * [portage]: mounting...

aug 09 14:29:21 gentoo systemd[1]: Started mount/umount all squashmount configured mount points.

gentoo ~ # mount

/dev/sda6 on / type ext4 (rw,noatime,nodiratime,discard,data=ordered)

devtmpfs on /dev type devtmpfs (rw,relatime,size=15925932k,nr_inodes=3981483,mode=755)

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)

tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)

devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)

tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)

tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)

cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)

efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)

cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)

cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)

cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)

cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)

cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)

cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)

cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)

cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)

cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)

cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)

systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)

mqueue on /dev/mqueue type mqueue (rw,relatime)

debugfs on /sys/kernel/debug type debugfs (rw,relatime)

tmpfs on /tmp type tmpfs (rw,nosuid,nodev)

hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)

tmpfs on /var/tmp type tmpfs (rw,relatime)

fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)

/dev/sda2 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-2,shortname=mixed,errors=remount-ro)

/dev/sdb2 on /mnt/date type fuseblk (rw,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,allow_other,blksize=4096)

/dev/sdb1 on /mnt/linux type ext4 (rw,noatime,nodiratime,data=ordered)

/dev/zram0 on /var/tmp type ext4 (rw,relatime,block_validity,discard,delalloc,barrier,user_xattr,acl)

tmpfs on /run/user/120 type tmpfs (rw,nosuid,nodev,relatime,size=3185456k,mode=700,uid=120,gid=998)

tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3185456k,mode=700,uid=1000,gid=1000)

binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)

/var/db.mount/db.sfs on /var/db.mount/readonly type squashfs (ro,noatime)

overlay on /var/db type overlay (rw,noatime,lowerdir=/var/db.mount/readonly,upperdir=/var/db.mount/changes,workdir=/var/db.mount/workdir)

/usr/portage.mount/db.sfs on /usr/portage.mount/readonly type squashfs (ro,noatime)

overlay on /usr/portage type overlay (rw,noatime,lowerdir=/usr/portage.mount/readonly,upperdir=/usr/portage.mount/changes,workdir=/usr/portage.mount/workdir)

```

I do not understand what the error is: overlay does not like to be bind mounted elsewhere, rbind is required ? I can make future tests, but I need some guidance/directions as my skills in this area are pretty much like try & error only.

Admin edit: Removed large chunks of "=" characters which forced an abnormally wide post layout. --pjp

----------

## mv

 *costel78 wrote:*   

> I do not understand what the error is: overlay does not like to be bind mounted elsewhere, rbind is required

 

bind and rbind should not make any difference.

But it might very well be that lack of binding possibility is yet another bug in overlay.

In my opinion, aufs is much better than overlay, but unfortunately, only the latter made it into upstream kernel; similar situation as with ZFS and btrfs.

----------

## costel78

I made some test with manual bind mount. It seems that parent directory (/srv/copy) have to be owned by portage, at least. Is possible to add new file, to delete, but there are still problems at rename, but, interesting, not always. At the same time, no problem with aufs (manually patched kernel). 

Thank you very much for your support!

----------

## mv

 *costel78 wrote:*   

> there are still problems at rename

 

I rechecked now with kernel-4.6.5, and it seems that the rename problem which I had reported has been solved. I am sure that this was not easy to solve, because the cause was somehow conceptual, and my guess is that to solve it, the code needs a way to "track" renames which apparently did not happen at all, before. There might now still be some cases which are not tracked correctly...

----------

## shrike

I have been experimenting with squashmount for a few days. Most recently I used a snippet from the squashmount man page but there is a parsing error:

```
# squashmount list

 * squashmount: fatal: failed to parse /etc/squashmount.pl:

                       Bad name after sfs' at /etc/squashmount.pl line 31.
```

```
 $ cat /etc/squashmount.pl

$lazy = $lsof = $lsof_ro = $squashfuse_ll = 1; # default

    $killpower = '/etc/killpower'; # ignore /etc/nosquash /etc/nut/killpower

    $locking = 1; # lock always, even for status and print-* commands

    $modprobe_loop = 1; # Keep default: modprobe loop

    $mksquash_verbose = 'qn-'; # quicker if we know mksquash -quiet works

    $processors = ''; # unnecessary; this is the default

    $mem = ''; # unnecessary; this is the default

    $resquash_on_start = ''; # unnecessary; this is the default

    $rm_rundir = 0; # keep /run/squashmount

    $rm_dir = $rm_workdir = $rm_changes = $rm_readonly = 0; # keep dirs

    @umount = ('-i'); # default to UMOUNT => [ '-i' ], ignoring --umount

    @umount_ro = (); # ignore option --umount-ro

    $obsolete_overlayfs = undef; # no fallback: require >=kernel-3.15

    @order = qw(overlay? overlayfs?);

    # The main task is to set @mounts. Use one of

    # @mounts = ( { ... }, { ...} );

    # push(@mounts, { ... }, { ... });

    # (The latter can be used successively to append mount-points...)

    @mounts = ( {

            # squashmount plays nicely with the portage's

            # sync-type = squashdelta

            # However, this requires another setup - see example

            configuration.

            # The following example is only useful for a "traditional"

            # sync-type (like rsync, webrsync or also git).

            TAG => 'portage', # TAG => 'gentoo' should be reserved for

            # /etc/portage/repo.postsync.d/10-squashmount-gentoo

            DIR => '/usr/portage,

            FILE => '/usr/portage.mount/portage.sfs',                          (Line 31)

            CHANGES => '/usr/portage.mount/changes',

            WORKDIR => '/usr/portage.mount/workdir',

            READONLY => '/usr/portage.mount/readonly',

            MKSQUASHFS => [ # Do not recompress git-compressed data

            # See https://github.com/plougher/squashfs-tools/issues/24

            '-action', 'uncompressed@subpathname(*/.git/objects/pack)' ],

            THRESHOLD => '40m', # resquash on umount if 40 MB changed, or

            # if local/* (with * not .git, profiles, metadata) changed:

            FILL => qr{^local/(?!(\.git|profiles|metadata)(/|$))}n,

            # The |profiles|metadata might be too much. Instead, you can be

            # be more explicit about the changes you do not care about, e.g.:

            # DIFF => qr{^local(/profiles(/use\.local\.desc)?)?$}n,

    });
```

Comparing this 'portage' mount with others from the man page example I see punctuation differences for TAG, DIR, and FILE. Bit rot?? Snippet incomplete?

Where am I going wrong?

Thanks,

Shrike

----------

## mv

 *shrike wrote:*   

> 
> 
> ```
> DIR => '/usr/portage,
> ```
> ...

 

This should be

```
DIR => '/usr/portage',
```

----------

## shrike

Success!

```
# squashmount list

 * [portage]: overlay/squashfs  (40m), modified, but will not resquash
```

```
# pydf

Filesystem Size Used Avail  Use%                                                                                                                                                               Mounted on

/dev/root  233G  11G  219G   4.9 [########..................................................................................................

.................................................] /

overlay    233G  11G  219G   4.9 [########...................................................................................................

................................................] /usr/portage

/dev/loop0  56M  56M     0 100.0 [##################################################################################################

#########################################################] /usr/portage.mount/readonly
```

Updating line 31 revealed another issue (~ line 25) with the word 'configuration' uncommented. 

Thanks !!

Shrike

Admin edit: Added line breaks to long lines of "." and "#" characters. --pjp

----------

## mv

 *shrike wrote:*   

> Updating line 31 revealed another issue (~ line 25) with the word 'configuration' uncommented. 

 

pod is somewhat unpredictable where newlines are inserted. I do not know how to properly fix that on a pod manpage..

----------

## pjp

I recently went through the ~20 pages and debated splitting it then. Since there has been new activity, I went ahead and split it (~20 pages is a soft maximum, so it was going to happen eventually). I've also added comments to the old thread referencing this one.

mv, you are welcome to change the thread title to something else if you prefer. I mainly tried to reflect the generic capability differentiating it from previous portage only/primarily solutions.

----------

## msst

Just wondering:

Has anyone compared this solution with btrfs-zstd compression in terms of space savings and speed? The KISS principle speaks in favour of the latter if you anway use btrfs. So what are the trade-offs?

----------

