problems with Nice and Dump in FreeBSD 6.1-Current (Stable-#5)

[backyard1454-bsd at yahoo.com]

--- 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
> of=/foo/bar.dbz2
> >
> >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
> if
> >I wish to continue, if I continue it fails. I will
> get
> >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
> being
> >corrupted.
> >
> >this exact command syntax works on everything but
> my
> >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.
> 
> --Alex
> 
> 
> 
> 

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
previous post.

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
anyway...


brian