[OpenAFS] fine-grained incrementals?

[Mike Fedyk]

Jeffrey Hutzelman wrote:

> On Wednesday, February 23, 2005 11:44:17 AM -0800 Mike Fedyk 
> <mfedyk@matchmail.com> wrote:
>
>>  1) r/w volumes pause all activity during a replication release
>>  2) backups need to show only the blocks changed since the last backup
>> (instead of entire files)
>>  3) (it seems) volume releases copy the entire volume image instead of
>> the changes since the last release
>>
>> It looks like all of these issues would be solved in part or completely
>> with the introduction of "Multiple volume versions" (as listed on the
>> openafs.org web site under projects).
>>
>> 1) would be solved by creating a clone before a release and releasing
>> from that.
>
>
> That already happens.  But the cloning operation takes time, and the 
> source volume is indeed busy during that time.

Interesting.  Is there documentation on the AFS format and how it does 
COW?  I'm familiar with Linux LVM, so it should use similar concepts, 
except that doing COW at the filesystem level can be more powerful and 
complicated than at the block device layer.

In LVM basically a snapshot/clone just requires a small volume for block 
pointers, and incrementing the user count on the PEs (physical 
extents).  How does AFS do this, and why is it taking a noticeable 
amount of time (also what is the AFS equivalent of PE block size)?

>
>> 2) would be solved by creating a clone each time there is a
>> backup and comparing it to the previous backup clone.  and 3) would be a
>> similar process with volume releases.
>
>
> This is not a bad idea.  Of course, you still have problems if the 
> start time for the dump you want doesn't correspond to a clone you 
> already have, but that situation can probably be avoided in practice.

Yes, and that is why I said it would be a specific and separate clone 
just for the incremental backups, so the timing isn't based on the 
backup clone for instance.

An interesting thought would be to clone a replicated volume on another 
machine that has more, but slower space than a fileserver holding the 
active r/w volumes and running the backups from that machine to keep 
load down on the r/w volume fileserver.

>
>
> Of course, there's a reason that "multiple volume versions" is not 
> done, and it has little to do with the ability to have multiple 
> clones.  The volserver _today_ supports up to 7 volumes per volume 
> group on namei servers, and quite a few more on inode servers.  You 
> can use 'vos clone' to create additional clones, but be careful unless 
> you really fully understand what you're doing.  Under normal 
> circumstances AFS will never use more than four volumes per volume 
> group (the R/W master, a backup clone, either a permanent RO clone or 
> a temporary release clone, and finally a temporary move clone when the 
> RW volume is the source of a move or copy).
>
>
> The hard part of the feature listed on the roadmap is figuring out how 
> to give clients the ability to refer to multiple versions of a volume, 
> so there can actually be a user-visible multi-level snapshot feature.

The first step can just allow the admin to mount the clone volumes where 
they want them.  OAFS allows you to have volumes that are not connected 
to the AFS tree that users see, doesn't it?

Mike