problems with Nice and Dump in FreeBSD 6.1-Current (Stable-#5)
backyard1454-bsd at yahoo.com
backyard1454-bsd at yahoo.com
Fri Jun 30 19:13:59 UTC 2006
--- Alex Zbyslaw <xfb52 at dial.pipex.com> wrote:
> backyard1454-bsd at yahoo.com wrote:
> >I forgot about nice being interal to csh, that is
> >likely to source of my problems...
> >I use this for a dump
> >dump -0 -C 32 -f - |bzip2 --best | dd
> >and then on a restore
> >bzip2 -dc | (cd /foo; restore -r -f -)
> >the error I get is
> >expected 234234 got 234237
> >expected 234235 got 234238
> >expected 234236 got 234239
> >... ...
> >expected 234250 got 234267
> >which fills up the screen with seemingly corruption
> >errors, then the restore bails with an error asking
> >I wish to continue, if I continue it fails. I will
> >a screen dump of the error when I can dig up the
> >corrupt dump file, and or make a new one. I believe
> >the error is something about inodes missing or
> >this exact command syntax works on everything but
> >usr filesystem.
> The restore man page does tell you why this happens
> (I know because I
> was just reading it today :-))
> You are doing this dump on a Live Filesystem. To do
> that use the -L
> option to dump (FreeBSD 5.X or later) which will
> snapshot the filesystem
> first. Either that, or do what we had to do for
> years and drop down to
> single-user mode and make sure no processes are
> running to change the
> filesystem. Dump needs the filesystem to be static.
> Then when you restore you will get precisely *one*
> similar "error" (at
> least on 5.4), which I can't explain but can say
> *does not matter*. I
> have restored several such dumps and compared them
> to the original
> filesystem and they are fine. You should do that
> yourself for your own
> peace of mind. (I do similar to you but with gzip
> and on 5.4).
> The "error" you'll get should be:
> expected next file <inumber>, got <inumber>
> A file that was not listed in the
> directory showed up.
> This can
> occur when using a dump created on an
> active file system.
> and I think it must be some artefact of the
> snapshot/dump interaction.
> If you use -L and *still* have trouble then it
> sounds like a bug.
I wasn't aware booting off the cd and running fixit
made my filesystems become live...
I have noticed myself this error occurs at least once
every once in a while and things are fine. I always
assumed the .snap directory from a newfs was at fault,
but because it always worked was never concerned until
a screen full of these errors occurred and restore
halted on me.
I suspect this is a bug because it looks like I forgot
the most important part of my dump command in my
dump -0 -C 32 -f - /dev/ad2s1f | ... ...
sorry about that I knew it didn't look right. I know I
had no issues with rel_5 on this matter, course I was
dumping and restoring to respective slices in one pipe
command. It was only when I tried on the laptop and
was forced to use a backup device to store the dumps
that this became an issue.
I will make another dump of my laptop when I'm am out
of work and post the results and or errors I
encounter. including the command lines verbatim as
typed into the shell. If I have to use tar its not
that big of a deal, but if it is a bug I would like
those with the ability to fix it have the correct
information they need. going to have to add C
programming to the yak-shaving list...
At present it is only conjecture. I will also check on
my server as it is a newer source build to see if I
get the same results. I will post the source version
as well when I remember how to I think a uname -a will
do the trick, but its something I should need to know
More information about the freebsd-questions