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 <[email protected]> > 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
