Re: dump woes

2005-04-22 Thread Dan Ponte
On Sat, Apr 23, 2005 at 06:05:25AM +1000, Peter Jeremy [EMAIL PROTECTED] was 
witnessed plotting the following conspiracy:
 On Thu, 2005-Apr-21 23:07:48 -0400, Dan Ponte wrote:
 I'm having a rather strange predicament with dump(8). First, I tried
 dumping a snapshot to a file within the filesystem being dumped like so:
 
  styx# dump -0u -a -L -C 8 -f /usr/backup/usr.dump /usr
 
 I then let it sit for a while. The filesystem was only 4.1GB, but the
 dump file was growing to almost 12GB!
 
 Try running fsck on the filesystem.  It's possible that there's some
 corruption that's confusing dump.
 
fsck seems to have run successfully. It did say incorrect block count,
but I told it to fix it. However, I am still seeing the negative tape
blocks problem.
-Dan
-- 
Dan Ponte
http://www.theamigan.net/
Comparing information and knowledge is like asking whether the fatness
of a pig is more or less green than the designated hitter rule.
-- David Guaspari
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dump woes

2005-04-22 Thread Peter Jeremy
On Thu, 2005-Apr-21 23:07:48 -0400, Dan Ponte wrote:
I'm having a rather strange predicament with dump(8). First, I tried
dumping a snapshot to a file within the filesystem being dumped like so:

   styx# dump -0u -a -L -C 8 -f /usr/backup/usr.dump /usr

I then let it sit for a while. The filesystem was only 4.1GB, but the
dump file was growing to almost 12GB!

Try running fsck on the filesystem.  It's possible that there's some
corruption that's confusing dump.

-- 
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: dump woes

2005-04-22 Thread Dan Ponte
snip
I hate to followup to my own message, however I believe that I have
identified a possible culprit (without solution, of course). Observe:
DUMP: estimated -1531206574 tape blocks.
DUMP: 99.99% done, finished soon
I suspect an integer overflow somewhere, but this is highly unusual
asI've seen many posts in various archives where the exact command
syntax I had was used, and it showed positive tape block calculations
and real percentages. This filesystem is only 17GB, with 4.1GB used (as
I said earlier).
-Dan
-- 
Dan Ponte
http://www.theamigan.net/
An age is called Dark not because the light fails to shine, but because
people refuse to see it.
-- James Michener, Space
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


dump woes

2005-04-21 Thread Dan Ponte
Hi all.
I'm having a rather strange predicament with dump(8). First, I tried
dumping a snapshot to a file within the filesystem being dumped like so:

styx# dump -0u -a -L -C 8 -f /usr/backup/usr.dump /usr

I then let it sit for a while. The filesystem was only 4.1GB, but the
dump file was growing to almost 12GB! I suspected recursion within the
dump (even though it shouldn't happen, as I was dumping the snapshot,
and the dump(8) code seems to create the snapshot and unlink it before
any dumping starts). So, I mounted an NFS filesystem on my workstation
and attempted to dump to it, like so:

styx# dump -0u -a -L -C 8 -S -f /mnt/wksback/usr.dump /usr

This time, it seemed to pause disk activity for a while, presumably
while it copied out to the network (in the pervious instance, the disk
activity LED was on constantly). My hopes were high until, again, the
dump grew in size:

 5.6G Apr 21 22:48 usr.dump

I stopped the dump and ran the following for the hell of it:

 tail usr.dump | strings
styx.cox.net
none
/usr
/dev/ad0s1f
styx.cox.net
none
/usr
/dev/ad0s1f
(repeat...)
Apparently, it's filling up the file with just NULLs and that! I am at a
loss as to what is happening.
Any insight in to the matter would be greatly appreciated.
Thanks,
-Dan


-- 
Dan Ponte
http://www.theamigan.net/
Brain, n.:
The apparatus with which we think that we think.
-- Ambrose Bierce, The Devil's Dictionary


pgptgJfgFuhfI.pgp
Description: PGP signature