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 ?
thanks,
chris hunter
chris.hunter@xxxxxxxx
"Experience is the teacher of all things." Julius Caesar
On 08/27/2015 06:46 PM, Theodore Ts'o wrote:
On Thu, Aug 27, 2015 at 03:28:12PM -0400, Chris Hunter wrote:
Hi,
Thanks for the response. As Theodore pointed out, the filesystem already had
extents. I ran the tune2fs command on a filesystem that had previously been
converted from ext3 to ext4. I undid features (via tune2fs -O ^<flag>) but
the read-only fsck errors persist.
Woah! If the file system already had been converted from ext3 to
ext4, why were you running the tune2fs command in the first place? I
had thought the tune2fs command was your _attempt_ to convert the
filesystem from ext3 to ext4. It was on that basis that I suggested
that you use the "tune2fs -O ^<flag>" command to revert those changes.
Can you elaborate on the risky tune2fs options. I assume you mean changes
that can't be undone ? or unsafe ?
There are commands to change the inode size (for example) that need to
allocate more blocks and then rewrite the inode table. These commands
are risky if your file system was corrupted before you attempt to run
the tune2fs command. For similar reasons, resize2fs forces you to do
a a read/write check of the file system (so that the last fsck time
can be updated, so resize2fs can *verify* that you ran the e2fsck
command, intsead of lazily claiming you did when you didn't :-)
*before* you run resize2fs.
The main issue here is that you want to make sure the file system is
in a stable state *before* you try to make involved changes. At this
point, I'm confused about what flags you had set on your file system
before you ran your tune2fs command, so it's hard to know what to
suggest. But it's highly likely that no matter what was going on, the
fact that your file system was corrupted has nothing to do with the
tune2fs command. The tune2fs -O command only flips a few bits in the
superblock. It's highly likely that your file system was corrupted
*before* you ran the tune2fs command.
It's for that reason that it's tempting to require an e2fsck before
running a tune2fs -O command. Unfortunately, in the past we've
allowed this even for mounted file systems, and if you know what you
are doing, and your file system is in a sane state, it's awfully
convenient to turn on certain features even while the file system is
mounted.
The problem is that if you are an enterprise distribution who has to
pay for staffing a help desk, or you're someone who's trying to help
someone who is asking for advice on linux-ext4, it's awfully tempting
to assume that we have to assume that users are idiots. And sometimes
it's not that they are, but because of ambiguities in bug reports.
For example, what was the state of your file system before you ran the
tune2fs command. Was it a stock ext3 file system, or had you already
converted it to ext4. If so, how? Was the file system mounted at any
of these steps? (Running e2fsck on a mounted file system is often
going to lead to misleading file system problem reports.)
So people who do this a lot often feel that tools have to be dumbed
down, because otherwise it becomes a support nightmare....
BTW, this is probably a good time to ask if your backups are up to
date. Because regardless of what happened, it's likely you will have
suffered at least some data loss...
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
