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
