linux-ext4 - Re: [PATCH 1/7] e2scrub: create online fsck tool of sorts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 2 Mar 2018 16:01:33 -0700
From:   Andreas Dilger <adilger@...ger.ca>
To:     "Darrick J. Wong" <darrick.wong@...cle.com>
Cc:     Theodore Ts'o <tytso@....edu>, djwong@...nel.org,
        linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/7] e2scrub: create online fsck tool of sorts

On Mar 2, 2018, at 12:35 PM, Darrick J. Wong <darrick.wong@...cle.com> wrote:
> 
> On Thu, Mar 01, 2018 at 02:17:17PM -0700, Andreas Dilger wrote:
>> On Mar 1, 2018, at 11:23 AM, Darrick J. Wong <darrick.wong@...cle.com> wrote:
>>> 
>>> From: Darrick J. Wong <darrick.wong@...cle.com>
>>> 
>>> 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.
>> 
>> One high-level note - in my lvcheck script, there was an option to disable
>> background checking if the system was running on a battery:
> 
> I don't think e2scrub or e2scrub_all should refuse to run if the system
> is on AC power -- if the user runs them from the cli then they shouldn't
> have to override that kind of decision to get what they asked for.
> 
> However, checking for AC power certainly makes sense for the background
> scrubber.  The systemd service description contains a predicate to
> disable the service if the system is running on a battery.  However, the
> cron job does not, so I will add that.

Good point, I didn't really notice that in the systemd service, since that
isn't my cup of tea.

>>> +mark_corrupt() {
>>> +	${DBG} "@root_sbindir@...ne2fs" -C 16000 -T "19000101" "${dev}"
>> 
>> This won't actually do anything if the time/mount-based checks are disabled
>> (which has been the default for a long time already, not that I agree with it).
>> You need to add something like "-i 720" to force a check on the filesystem on
>> the next mount.
> 
> The trouble with this (all of it, really) is that this clobbers whatever
> setting the administrator might have written into the superblock.  Given
> that corruption failures will be logged and produce emailed reports, I
> wonder if it would be easier to dispense with the force-fsck part
> entirely?

How about adding an option to tune2fs to mark the filesystem in error
from userspace, so there is no need to mess with the timestamps or clobber
the time-based fsck settings in the superblock?  "-E" would have been good
to match "-e errors_behaviour", but it is already used.  Other options
include "-E force_fsck" or "-F", or something else.

Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)