Thanks everybody for their help.
As it turns out, I guess dump was being starved for memory, as
running it while booted into FreeBSD normally using -L to indicate a
live filesystem worked just fine. I believe this is because there is
an extra swap file available from a normal FreeBSD boot, as specified
in my /etc/rc.conf. I'm not sure if my theory completely holds up,
but there you have it.
Thanks again! I'm up and running...
On Feb 16, 2006, at 9:25 AM, Lowell Gilbert wrote:
Joe Auty <[EMAIL PROTECTED]> writes:
I'm running 5.4. Perhaps restore is generating this particular error
message? I don't know.
It would be hard to tell, without an intermediate disk to write the
data to so you can separate the dump from the restore. You might be
able to trace one of the processes to see, but that requires a bit of
technical knowledge.
I may have to go this route, see if I can put together the disk space
to manage this. Is there a way to get tar to just extract directly to
a destination directory so I don't have to contend with a single
large tarball I need to create disk space for?
Sure. As far as I'm concerned, that's the normal way to copy
directory trees. You just pipe the output of the tar process into
another tar process that un-tars it in another place.
E.g.:
tar -C ~/work/debugger -cf - . | tar -C temp -xf -
My disk is over a 100 gigabytes, could this be
what
is causing dump to crap out?
Could be. Check your memory statistics while you're doing it,
and see
if you run out of VM.
What is a good strategy for dealing with this possibility, should I
go down that path?
Start by watching top(1) while it's running...
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-
[EMAIL PROTECTED]"
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
