RE: ufsdump restarts dump after hitting EOT

Makes sense to me, but I come from a differnet background...

I suspect, but have not investigated, that ufsdump has some sort of "spanning" option, so that backups can
span multiple volumes, but again, you would have to specifythe size of your media. It appears that ufsdump
doesn't know it is out of tape, until it it sout of tape, and by then it is too late to "close the file" and move
on to the next volume. When it gets to the end of the tape, it actually encounters a write error, which causes
it to start over.

That is what it seems like to me, anyway.

Ken
===
Ken Hansen

> -----Original Message-----
> From: Paul Keusemann [mailto:pkeusem <at> isis.visi.com] 
> Sent: Tuesday, January 07, 2003 9:55 PM
> To: suns-at-home <at> net-kitchen.com
> Subject: [Suns-at-Home] ufsdump restarts dump after hitting EOT

<snip>

> I backup using the non-rewind device so all filesystems
> get dumped one after another.
> 
> The problem is that whenever I hit end of tape, the dump of 
> the current filesystem is restarted from the beginning on the 
> next tape wasting a lot of time and tape.

Sounds like a write error condition to me...

> If I specify the size of the tape, the dump is continued on
> the next tape without restarting.

> Is this brain damage in ufsdump or in the FreeBSD rmt 
> implementation? Or are my expectations too high?  My FreeBSD 
> and Linux machines all manage to split filesystem dumps 
> across tapes when necessary.

Probably just different default settings, take a look at the defaults between the two...