All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Turmel <philip@turmel.org>
To: Luigi Fabio <luigi.fabio@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: RAID5 failure and consequent ext4 problems
Date: Sat, 10 Sep 2022 16:15:55 -0400	[thread overview]
Message-ID: <4214394e-6f73-6ee9-08ce-2ba95b8e0713@turmel.org> (raw)
In-Reply-To: <CAJJqR20PcvMs5e3cKXf8DtLF_nVthii4rbkFLPYZ4QT7mpj0Kg@mail.gmail.com>

Do the fsck with an overlay in place.

I suspect the data in the inodes will provide corroboration for newer 
data in the various structures.  I think your odds are good, now.

On 9/10/22 16:12, Luigi Fabio wrote:
> Following up, I found:
> 
>>> The backup ext4 superblocks are never updated by the kernel, only after
>>> a successful e2fsck, tune2fs, resize2fs, or other userspace operation.
>>>
>>> This avoids clobbering the backups with bad data if the kernel has a bug
>>> or device error (e.g. bad cable, HBA, etc).
> So therefore, if we restore a backup superblock (and its attendant
> data) what happens to any FS structure that was written to *after*
> that time? That is to say, in this case, after Aug 18th?
> Is the system 'smart enough' to do something or will I have a big fat
> mess? I mean, reversion to 08/18 would be great, but I can't imagine
> that the FS can do that, it would have to have copies of every inode.
> 
> This does explain how I get so many errors when fsck grabs the backup
> superblock... the RAID part we solved just fine, it's the rest we have
> to deal with.
> 
> Ideas are welcome.

  reply	other threads:[~2022-09-10 20:16 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-08 14:51 RAID5 failure and consequent ext4 problems Luigi Fabio
2022-09-08 17:23 ` Phil Turmel
2022-09-09 20:32   ` Luigi Fabio
2022-09-09 21:01     ` Luigi Fabio
2022-09-09 21:48       ` Phil Turmel
2022-09-09 22:11         ` David T-G
2022-09-09 22:50         ` Luigi Fabio
2022-09-09 23:04           ` Luigi Fabio
2022-09-10  1:29             ` Luigi Fabio
2022-09-10 15:18               ` Phil Turmel
2022-09-10 19:30                 ` Luigi Fabio
2022-09-10 19:55                   ` Luigi Fabio
2022-09-10 20:12                     ` Luigi Fabio
2022-09-10 20:15                       ` Phil Turmel [this message]
2022-09-10 20:14                     ` Phil Turmel
2022-09-10 20:17                       ` Phil Turmel
2022-09-10 20:24                         ` Luigi Fabio
2022-09-10 20:54                           ` Luigi Fabio
2022-09-12 19:09                     ` Phillip Susi
2022-09-13  3:58                       ` Luigi Fabio
2022-09-13 12:47                         ` Phillip Susi
2022-09-12 19:06                 ` Phillip Susi
2022-09-13  4:02                   ` Luigi Fabio
2022-09-13 12:51                     ` Phillip Susi

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=4214394e-6f73-6ee9-08ce-2ba95b8e0713@turmel.org \
    --to=philip@turmel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=luigi.fabio@gmail.com \
    /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.