Phil, I did indeed go there, but, stupidly, after the fact and I had missed the reference to your tool. Not an excuse, but the initial part of the process was, as I mentioned, complicated and done while driving.... I'll download lsdrv and snapshot the situation in any case, generate the overlay, run the fsck and see what happens. I'll report back when it's done, which is probably going to be tomorrow (fsck times for this filesystem historically have been in the 9+ hr range - and the overlay will probably do us no favours performancewise). Back as soon as I have further data. Thank you again for the help. L On Sat, Sep 10, 2022 at 4:17 PM Phil Turmel <philip@xxxxxxxxxx> wrote: > > Oh, one more thing: > > If you had followed any of the advice on the linux-raid wiki, you'd have > been pointed to my lsdrv project on github: > > https://github.com/pturmel/lsdrv > > (Still just python2, sorry.) > > > On 9/10/22 16:14, Phil Turmel wrote: > > Hi Luigi, > > > > > > On 9/10/22 15:55, Luigi Fabio wrote: > >> Well, I found SOMETHING of decided interest: when I run dumpe2fs with > >> any backup superblock, this happens: > >> > >> --- > >> Filesystem created: Tue Nov 4 08:56:08 2008 > >> Last mount time: Thu Aug 18 21:04:22 2022 > >> Last write time: Thu Aug 18 21:04:22 2022 > >> --- > >> > >> So the backups have not been updated since boot-before-last? That > >> would explain why, when fsck tries to use those backups, it comes up > >> with funny results. > > > > Interesting. > > > >> Is this ...as intended, I wonder? Does it also imply that any file > >> that was written to > aug 18th will be in an indeterminate state? That > >> would seem to be the implication. > > > > Hmm. I wouldn't have thought so, but maybe the backup blocks don't get > > updated as often? > > > > { I think you are about as far as I would have gotten myself, if I > > allowed myself to get there. } > > > > Phil >
