[OpenAFS-devel] Re: Backups using commercial products

[Lyle Seaman]

Mitch Collinsworth wrote:

> On Wed, 3 Jan 2001, Ken Hornstein wrote:
>
> > I thought that locking the volume would have been sufficient; doesn't
> > that do anything?
>
> Don't know.  I was asking the same question.  Lyle's comments above
> were addressing the context of doing a direct volume dump from the
> file server without going through the volserver (i.e. not using vos
> dump or backup dump).  I was just wondering out loud if in the
> presence of the same competing accesses this is a non-issue when
> doing the dump "the normal way".

yes, the "locking" is all internal to the volserver/fileserver
relationship, and some operations are compatible with each
other.  Thus, you should (theoretically, anyway) be able to
dump the same volume twice at the same time.  But the
volserver won't move it away while it's dumping.

There's a TCP connection between the file and vol servers
that is used for negotiating who can do what with a volume.

You could add a mechanism for external lockers, the tricky
part that I was hinting at is what do you do when the external
locker goes away without releasing the lock, et cetera.

Building a new physical filesystem is easier said than done,
and in any case, I'm not sure that vos dump is the most
performance-critical operation.  Surely there are other
things (read,write,fetchstatus) that would take precedence?

The quickest and most straightforward means of speeding
a single vos dump are:
1. use TCP instead of (or in addition to) RX.
2. add some kernel code that takes
hints about what are the next half-dozen disk blocks that
you're going to be looking for, and prefetches them
simultaneously, so you can keep the seek times low.
But that wouldn't be terribly portable, as it would have to
be different for every physical filesystem.
3. Some physical filesystems can make predictions
about the relative physical distance between two pairs
of inodes, knowing only their logical inode numbers.
Put another way, for most filesystems, inodes 5 and 7
are closer together than inodes 7 and 92 are.  In that
case, it would make sense to sort the LargeVnode and
SmallVnode lists together by inode number before dumping.
But off the top of my head I'm not sure whether the volume
dump format could handle it.   I think so.