Coda File System

Re: problems with truncated backups

From: Jan Harkes <>
Date: Wed, 21 May 2003 12:59:11 -0400
On Wed, May 21, 2003 at 01:03:19AM -0700, Steve Simitzis wrote:
> on the backup machine, i see this:
> 00:48:53 Dumping 7f000005.1000006 to /usr/backup/21May2003/ ...
> 00:48:55                Transferred 4902360 bytes
> however:
> 91 /usr/backup/21May2003: sg4> ls -l
> total 1512
> -rwxr-xr-x    1 root     root       511998 May 21 00:48
> as you can see, the actual file is much less than 4902360 bytes!
> every backup i've tried turns out to be right around the same size
> (512000 bytes), even though the correct amount of data is reported as
> transfered.

Interesting that is the size of a single 'dump buffer'. The server sends
the data back by using individual RPCs that each ship up to 512000 bytes
back to the client. With this RPC we include the offset of that block
within the stream, which is actually a bad thing as it prevents us from
dumping more than 4GB per volume. But the point is that this offset is
passed down to RPC2 which should seek to the right place before
writing the next batch of data to disk.

Interestingly, I've been using Amanda for backups, and there we simply
write the dumped data to stdout, it is already serialized by the server,
so we don't really need to seek. My backups do end up the right size.
So something must have broken in librpc2 where it doesn't seek to the
right offset before writing the next batch of data to the dumpfile.

> there is also this one, which seems to be an odd case:
> 00:48:55 Dumping 7f000004.1000005 to /usr/backup/21May2003/ ...
> 00:56:58                Transferred -1753755496 bytes

Looks like it actually transferred 2541211800 bytes, which is more than
2GB, probably a %ld that really should be a %lu.

> i have followed the instructions quite closely, and i've been certain
> to specify a full backup rather than an incremental. there is plenty
> of disk space in the backup filesystem, so i'm at a loss as to why
> it's not actually creating the backups.

I'll have a look at rpc2.

Received on 2003-05-21 13:05:24