All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Hunter <chris.hunter@yale.edu>
To: linux-ext4@vger.kernel.org
Cc: tytso@mit.edu
Subject: Re: errors following ext3 to ext4 conversion
Date: Thu, 27 Aug 2015 15:28:12 -0400	[thread overview]
Message-ID: <55DF64CC.8060201@yale.edu> (raw)
In-Reply-To: <20150827185845.GB3357@thunk.org>

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@yale.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
>

  reply	other threads:[~2015-08-27 19:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-27  0:53 errors following ext3 to ext4 conversion Chris Hunter
2015-08-27  3:39 ` Theodore Ts'o
2015-08-27  3:43   ` Eric Sandeen
2015-08-27  4:15     ` Darrick J. Wong
2015-08-27 18:58       ` Theodore Ts'o
2015-08-27 19:28         ` Chris Hunter [this message]
2015-08-27 22:46           ` Theodore Ts'o
2015-08-28 16:23             ` Chris Hunter
2015-08-28 18:32               ` Theodore Ts'o
2015-08-27 21:34         ` Eric Sandeen
2015-08-28 16:09 ` Andreas Dilger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55DF64CC.8060201@yale.edu \
    --to=chris.hunter@yale.edu \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.