linux-ext4 - Re: errors following ext3 to ext4 conversion

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, 28 Aug 2015 14:32:13 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Chris Hunter <chris.hunter@...e.edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: errors following ext3 to ext4 conversion

On Fri, Aug 28, 2015 at 12:23:54PM -0400, Chris Hunter wrote:
> Hi Theodore,
> 
> You are correct there were human errors in these filesystem changes (eg.
> insufficient pre-checks/validation). I don't expect the software to
> compensate for poor planning.
> For future reference, I desire a better understanding of risks involved in
> using tune2fs. I incorrectly assumed that tune2fs doesn't "do" anything
> until a filesystem is mounted.
> Assuming you start with a clean filesystem, which tune2fs commands are the
> most dangerous ? which are the safest ?

In the e2fsprogs 1.42.x series (which is what you are using), the only
really "dangerous" option is "tune2fs -I", which changes the inode
size and require moving blocks around and which could potentially
cause data loss if you lose power while the tune2fs command is
running.

You're posting on the ext4 developer's mailing list, and there have
been discussions to add more "resize2fs-like" features to tune2fs in
the 1.43 development branch of e2fsprogs.  For the *most* part the
commands in tune2fs are "safe" in that they don't touch anything other
than the superblock --- although if the file system is mounted, they
can result in changes right away.

The one command which can have more traps for the unwary is "tune2fs
-O".  It only modifies the superblock, but in some cases, tune2fs will
ask you to run e2fsck afterwards.  We do try to mask out the dangerous
options --- for example, we don't allow you to turn off the extents
option, since that cause problems.  Someone who accidentally enabled
the extents flag on a file system that previously didn't, and while it
is unmounted, can turn it off using debugfs but that _is_ dangerous so
we don't allow tune2fs to do so.

So we do try to make tune2fs safer for non-experts.  In this
particular case, I got a bit frustrated because we got the typical bug
report, and I apologize for my tone.  For some reason, users tend not
to give us relevant information (such as this is a Lustre disk) as
background context, and in some cases, outright *wrong* information
(that this was an ext3 file system that you were converting to ext4;
from what you've said later, apparently this was already had some ext4
features because it was used as a part of Lustre).  This is the sort
of thing that gives support engineers nightmares, and it's why develop
people like myself who are developers sometimes don't make good
support engineers --- we don't have the protective assumptions from
long experience that everything a user asking for help tells us may be
lies.  :-)

						- Ted

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html