Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: bad dir ino panic

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 <>
>     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
SALVAGE? [yn] y

1803739858656361606 BAD I=94542691
6305850363569970734 BAD I=94542691
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!



Home | Main Index | Thread Index | Old Index