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
| ||
|
Date: Thu, 27 Aug 2015 15:28:12 -0400 From: Chris Hunter <chris.hunter@...e.edu> To: linux-ext4@...r.kernel.org Cc: tytso@....edu Subject: Re: errors following ext3 to ext4 conversion 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. Can you elaborate on the risky tune2fs options. I assume you mean changes that can't be undone ? or unsafe ? regards, chris hunter chris.hunter@...e.edu On 08/27/2015 02:58 PM, Theodore Ts'o wrote: > On Wed, Aug 26, 2015 at 09:15:36PM -0700, Darrick J. Wong wrote: >> >> tune2fs is not as strict as resize2fs; iirc resize whines if it finds ERROR >> status, lack of VALID status, or it having been too long since the last fsck, >> whereas tune2fs only cares that the fs is marked VALID. >> >> (Scary, if you think about it...) > > Originally tune2fs was for things like changing the number of reserved > blocks in the superblock, or setting a label, etc. Things for which > subtle file system corruptions wouldn't be that big of a deal. > > Even for setting feature flags, tune2fs doesn't make any fundamental > changes to the file system other than flipping a few bits. So for > Chris, the good news is that undoing the tune2fs changes is relatively > easy if all he's done since then is to run a read-only e2fsck -n run. > We just have to flip a few bits. (Note, the reason why I didn't > include ^dir_index is that most ext3 file systems created using > non-paleolithic versions of e2fsprogs will have dir_index turned on > already.) > > But now that we have some tune2fs operations that do resize2fs-like > operations, we probably should add checks for those more risky > operations. And even though feature-flags flipping isn't very scary > in and of itself, requiring maybe we should require it for that case > --- although we have historically supported adding things like the > extents flag, or even the journal when converting from ext2 to ext3, > while the file system was mounted. > > I suspect that would fill Eric's heart with horror, but the ability to > migrate the root file system from ext2 to ext3 while it was mounted > (i.e., just run "tune2fs -O has_journal /dev/rootfs" and reboot) was > something Stephen Tweedie added, so at least at one point Red Hat was > more adventurous about what it would support in terms of file system > upgrades without using mkfs. :-) > > - 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
Powered by blists - more mailing lists