In the case where mkdir -p is not thread-safe (for example, if the
build environment is using busybox's mkdir) the configure script will
fall back to the slow (but safe) install-sh script. In that case
MKDIR_P will be using a relative pathname; so we can't use speed
optimization of defining configure substitutions in MCONFIG.in, since
the substitution will be different depending on depth of the
subdirectory in the Makefile.in file.
https://github.com/tytso/e2fsprogs/issues/51
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The two second sleep is only needed in e2scrub, and when there is a
failure, so that systemd has a chance to gather the log output before
e2scrub exits. It's not needed if the script is exiting successfully,
and it's never needed for e2scrub_all ever.
Addresses-Debian-Bug: #948193
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
gregor herrmann reports that the weekly e2scrub cronjob emits these
errors:
/sbin/e2scrub_all: line 173: /proc/8234/fd/pipe:[90083173]: No such file or directory
The root cause of this is that the ls_targets stdout is piped to stdin
to the entire ls_targets loop body to prevent the loop body from reading
the loop iteration items. Remove all the broken hackery by reading the
target list into a bash array and iterating the bash array.
Addresses-Debian-Bug: #944033
Reported-by: gregor herrmann <gregoa@debian.org>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Dave Chinner complains that the automated on-boot e2scrub reaping takes
a long time (because the lvs command can take a while to run) even
though the automated e2scrub is disabled via e2scrub.conf on his
systems.
We still need the reaping service to kill off stale e2scrub snapshots
after a crash, but it's unnecessary to annoy everyone with slow bootup.
Because we can look for the e2scrub snapshots in /dev/mapper, let's
skip reaping if periodic e2scrub is disabled unless we find evidence of
e2scrub snapshots in /dev.
Reported-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Some versions of cron leave fd 3 open for some unknown reason. So
when e2scrub_all is run by cron (on non-systemd systems) this results
in an annoying message from the Cron Daemon because lvm will print
warning messages about "leaked file descriptors. So force close fd 3
at the beginning of e2scrub and e2scrub_all.
Addresses-Debian-Bug: #940240
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If the volume group's free space is exactly the same as snapshot size,
e2scrub_all will skip those logical volumes in those volume groups.
Fix this by changing the test from '>' to '>='.
Fixes: c120312253 ("e2scrub_all: make sure there's enough free space...")
Addresses-Debian-Bug: #935009
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Since e2scrub_all.cron is marked as a config file, it can hang around
after the package is removed, in which case e2scrub_all might not be
present. So check to make sure e2scrub_all exists before trying to
execute it.
Addresses-Debian-Bug: #932622
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reported-by: Laurent Bigonville <bigon@debian.org>
By default, e2scrub_all will not actually trigger online scrubs unless
periodic_e2scrub=1 is set in /etc/e2scrub.conf.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The e2scrub_all program was broken by commit c7d6525eca
("e2scrub_all: refactor device probe loop") so that it would use the
path of the snapshot volume instead of the base volume. This caused
"e2scrub_all -r" to pass the wrong pathname to e2scrub, with the
result that e2scrub would abort with an error instead of removing the
snapshot volume.
Fixes: c7d6525eca ("e2scrub_all: refactor device probe loop")
Addresses-Debian-Bug: #931679
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
We handle the case where an LVM's PV is stacked on top of a dm-crypt
device, but not the case where it's the other way around, where a LVM
LV contains a LUKS encrypted file system. Fix this oversight.
Addresses-Debian-Bug: #931387
Reported-by: Marc Haber <mh+debian-bugs@zugschlus.de>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
We already have the "SERVICE_MODE=1" feature that signals to e2scrub
that we're running as a background daemon and therefore we should exit
quietly if conditions aren't right.
It's therefore unnecessary to have a separate -C flag to achieve the
same outcome for cron jobs. Merge the two together.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Running lsblk when there are no valid block devicse results in
generating all block devices as the list of devices to scrub; this
results in a lot of e2scrub_all failures.
Addresses-Debian-Bug: #929186
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
In scrub/Makefile the various 'install-*' targets do not explicitly
depend on their corresponding 'installdirs-*' target, so they get run
in parallel.
Addresses-Gentoo-Bug: #680030
Signed-off-by: Lars Wendler <polynomial-c@gentoo.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Paul Menzel reported that the e2scrub_all reaper service that runs at
startup takes a long time to run, and Ted Ts'o pointed out that we could
do a lot less work by using lvs as the outer loop in the ext4 filesystem
probe function so that we only have to lsblk the lvm devices containing
ext4 filesystems.
Therefore, refactor the loops to put lvs first, which should boost speed
a bit.
[ Made some of the further optimizations suggested by Lukas Czerner. -- TYT ]
Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If there isn't, skip the volume so we don't spam the system
administrator with error messages. It's quite commkon that there is
is zero free space in the volume group.
Addresses-Debian-Bug: #924301
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Not all systems will have the lvm2 package installed, so check for
that. Pretty much all systems should have util-linux installed, but
check for that as well.
Of course, if lvm2 is installed we shouldn't find any LVM devices ---
but eventually the Demon Murphy will find a way to make it happen. :-)
Also, set the PATH so we don't have to worry about the script failing
due to /sbin not being in the path.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Apparently newer versions of systemd than the one on this author's
laptop <cough> now complain about lack of (path) escaping in unit
instance variable contents:
# e2scrub_all
Scrubbing /home...
Invalid unit name "e2scrub@/home" was escaped as "e2scrub@-home"
(maybe you should use systemd-escape?)
Starting Online ext4 Metadata Check for /home...
So change the escape_path_for_systemd function to escape paths
unconditionally to make the warning go away.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Fix the MKINSTALLDIRS -> MKDIR_P transition in the scrub/ dir.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Add the ability to run the e2scrub utilities as a periodically scheduled
system service.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Create an e2scrub_all command to find all ext* filesystems
and run an online scrub against them all.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Implement online fsck for ext* filesystems which live on LVM-managed
logical volumes. The basic strategy mirrors that of e2croncheck --
create a snapshot, fsck the snapshot, report whatever errors appear,
remove snapshot. Unlike e2croncheck, this utility accepts any LVM
device path, knows about snapshots running out of space, and can call
fstrim having validated that the fs metadata is ok.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
