| View previous topic :: View next topic |
| Author |
Message |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
 Posted: Wed Feb 25, 2015 11:46 am Post subject: |
 |
|
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). |
|
| Back to top |
|
 |
gringo
Advocate
Joined: 27 Apr 2003
Posts: 3793
|
| Posted: Wed Feb 25, 2015 11:49 am Post subject: |
|
|
| 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 ! |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Wed Feb 25, 2015 11:56 am Post subject: |
|
|
| 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). |
|
| Back to top |
|
|
gringo
Advocate
Joined: 27 Apr 2003
Posts: 3793
|
| Posted: Wed Feb 25, 2015 12:36 pm Post subject: |
|
|
| 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.
| Code: | | 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 ! |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Wed Feb 25, 2015 1:14 pm Post subject: |
|
|
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:
| Code: | 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
| Code: | 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). |
|
| Back to top |
|
|
gringo
Advocate
Joined: 27 Apr 2003
Posts: 3793
|
| Posted: Wed Feb 25, 2015 2:16 pm Post subject: |
|
|
| 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 :
| Code: | #!/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.
modprobe overlayone thing im thinking of : could it maybe be related to the fact that in this system /usr/portage is a symlink to /var/repos/portage ?
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 |
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 ! |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Wed Feb 25, 2015 2:40 pm Post subject: |
|
|
| gringo wrote: | | @order = ( 'unionfs-fuse' ); |
It might be a problem with unionfs-fuse. With unionfs-fuse, the second "mount" command should be instead:
| Code: | | 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). |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Fri Feb 27, 2015 6:24 am Post subject: |
|
|
| 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). |
|
| Back to top |
|
|
costel78
Guru
Joined: 20 Apr 2007
Posts: 407
|
| Posted: Fri Feb 27, 2015 8:41 am Post subject: |
|
|
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.
_________________
Sorry for my English. I'm still learning this language. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Fri Feb 27, 2015 9:18 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Massimo B.
Veteran
Joined: 09 Feb 2005
Posts: 1842
Location: PB, Germany
|
| Posted: Sun Mar 01, 2015 7:28 pm Post subject: |
|
|
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? | Code: | >>> 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.
_________________
HP ZBook Power 15.6" G8 i7-11800H|HP EliteDesk 800G1 i7-4790|HP Compaq Pro 6300 i7-3770 |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Mar 01, 2015 9:12 pm Post subject: |
|
|
| 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 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. |
|
| Back to top |
|
|
Massimo B.
Veteran
Joined: 09 Feb 2005
Posts: 1842
Location: PB, Germany
|
| Posted: Mon Mar 02, 2015 1:42 pm Post subject: |
|
|
OK, so here I have that issue again: | Code: | # 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: | Code: | #!/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 |
_________________
HP ZBook Power 15.6" G8 i7-11800H|HP EliteDesk 800G1 i7-4790|HP Compaq Pro 6300 i7-3770 |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Mon Mar 02, 2015 9:14 pm Post subject: |
|
|
| Massimo B. wrote: | OK, so here I have that issue again: | Code: | # 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 |
|
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) |
|
| Back to top |
|
|
Petros
n00b
Joined: 28 Mar 2015
Posts: 50
|
| Posted: Sat Mar 28, 2015 5:54 pm Post subject: |
|
|
Hey there @mv. You have done such an excellent job with squashmount. Thank you, portage and eix are faster now  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 | Code: | | emerge -av @preserved-rebuild |
on my machine. But portage was complaining this :
| Code: | | 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
| Code: | #!/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. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sat Mar 28, 2015 9:17 pm Post subject: |
|
|
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:
| Code: | my $defaults = {
COMPRESSION => 'lz4',
COMPOPT_LZ4 => '',
}; |
Since you do not refer to this variable later, it is pointless to set it.
| Code: | 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.
Do you have a reason to set this?
The last line in your config-file should be (although your above last line should work too, by accident). |
|
| Back to top |
|
|
Petros
n00b
Joined: 28 Mar 2015
Posts: 50
|
| Posted: Sat Mar 28, 2015 9:42 pm Post subject: |
|
|
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 portage can no longer find the ebuild. As soon as I run the problem disappears. Other packages from this overlay are visible. It is not masked; besides that portage finds it just fine when I run
I noticed and measured eix-update to be faster tha way. Before squashing the directory I measured 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 |
|
| Back to top |
|
|
Petros
n00b
Joined: 28 Mar 2015
Posts: 50
|
| Posted: Sat Mar 28, 2015 10:31 pm Post subject: |
|
|
After updating all overlays 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? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sat Mar 28, 2015 10:46 pm Post subject: |
|
|
| 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). |
|
| Back to top |
|
|
Petros
n00b
Joined: 28 Mar 2015
Posts: 50
|
| Posted: Sat Mar 28, 2015 11:04 pm Post subject: |
|
|
Oh I see  Thank you. |
|
| Back to top |
|
|
Petros
n00b
Joined: 28 Mar 2015
Posts: 50
|
| Posted: Mon Mar 30, 2015 4:03 pm Post subject: |
|
|
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 :
| Code: | #!/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; |
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Mon Mar 30, 2015 9:07 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Petros
n00b
Joined: 28 Mar 2015
Posts: 50
|
| Posted: Tue Mar 31, 2015 11:55 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Tue Mar 31, 2015 4:58 pm Post subject: |
|
|
| 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... |
|
| Back to top |
|
|
Petros
n00b
Joined: 28 Mar 2015
Posts: 50
|
| Posted: Tue Mar 31, 2015 7:32 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
|
 |
Gentoo Forums Forum Index
 Documentation, Tips & Tricks |
All times are GMT
Goto page Previous 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 Next
|
| Page 6 of 10 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
