Re: bad dir ino panic

[Patrick Welche <prlw1%cam.ac.uk@localhost>]

On Sun, Jun 07, 2020 at 08:56:30PM +0700, Robert Elz wrote:
>     Date:        Sun, 7 Jun 2020 12:45:12 +0100
>     From:        Patrick Welche <prlw1%cam.ac.uk@localhost>
>     Message-ID:  <20200607114512.GA3989@quantz>
> 
>   | /store/backup is a ffsv2+wapbl on cgd on raidframe that was just
>   | filled up with a "dump -0auXf - /olddisk | restore rf -",
> 
> How was it mounted when that was done?    (I odten mount the dest
> filesystem "-o async" (and definitely not -o log which is incompat)

I am not sure - I didn't realise that log was a bad idea! I have log in
fstab, but chances are I had only just created the directory and
mount /dev/dk32 /store/backup

I only use async on /usr/obj - hadn't thought of using it for fast
level 0 restores...

> when doing this kind of transfer, as without the filesystem consistency
> promises, it is much much faster - and if anything goes wrong, a newfs
> and start again is trivial to do.   But if that's done and you don't
> properly umount and remount (without async) afterwards, weird filesystem
> problems can occur (because of inconsistent data actually written to the
> device).
> 
> What did a "fsck -f" say about the filesystem afterwards?

It just produced some output while reading this :-)

# fsck /store/backup
** /dev/rdk32
** File system is clean; not checking
# fsck -f /dev/rdk32
** /dev/rdk32
** File system is already clean
** Last Mounted on /store/backup
** Phase 1 - Check Blocks and Sizes
PARTIALLY TRUNCATED INODE I=94542691
SALVAGE? [yn] y

1803739858656361606 BAD I=94542691
6305850363569970734 BAD I=94542691
PARTIALLY TRUNCATED INODE I=94542711
SALVAGE? [yn] y
...

>   | Essentially, does that mean there was a problem with olddisk which was
>   | faithfully recreated, or something to worry about?
> 
> Definitely not "faithfully recreated" - restore uses standard filesystem
> calls (the same as any other normal application) to write the files it
> is recovering (transferring in this usage) - and while dump (since it
> reads from the raw device) could conceivably send something that made
> no sense, all restore can do in that case is complain - it has no
> mechanism to create faulty filesystem data.

So if the old disk had suffered from years of
** File system is clean; not checking
and had issues, what I see above was definitely created by the restore part
on the new disk?

> What version system (and what update date if it is HEAD, or anything_STABLE)
> was used for this?

It was HEAD from June 6 13:54 UTC. Using fsdb I found the directory (deep
in the tree) which the panic came from, but given the fsck -f, the partition
has more problems.

I will try another (16 hour - maybe I had better try async) dump restore
making sure log is off.

Thank you for the tips!


Cheers,

Patrick