[OpenAFS-devel] Re: some requests

[Jeffrey Hutzelman]

On Monday, February 21, 2005 01:57:20 PM +0100 Peter Somogyi 
<psomogyi@gamax.hu> wrote:

># 01:
> "extend the vos examine command with the parameters -server
> -partition  to do a bulk vos examine for a server or for a server specific
> partition ."
>
> "bulk" means here multiple volume listing (textual).
>
> Plan:
> - modify src/volser/vos.c

Before I can comment on this, I need to understand how it is different from 
what 'vos listvol -long' already does.



># 02:
> "an additional "flag" inside VLDB where we update a counter each time a
> file within a specific volume was updated (needed to query volumes which
> are worth to backup) which can be explored with vos examine and can be
> reseted to zero with the vos setfield command (and over the api)"
>
> Plan:
> - a spare afs_int32 must be reserved from VolumeDiskData as counter
> - volume header must be updated on each file change => modify fileserver
> - counter reaches maximum: doesn't overflow, remains max
> - cmd line option: for example "-counter_reset"
> - one volint.xg/volintInfo.spare2 bit is needed
> - api modification to support querying and reseting this field

I don't understand where the VLDB comes into this; the VLDB and the volume 
headers are not the same thing.

What are you trying to accomplish that you cannot get by comparing the 
volume's last-modified date to its backup date?  Would it help you to have 
a timestamp in the volume header that your backup system can set whenever 
it backs up a volume?

FWIW, my experience suggests that it is better for a backup system to 
decide what volumes to back up based on the last-modified timestamps on the 
volumes and on information the backup system has about what previous 
backups it has available.  An incremental dump based on a timestamp 
maintained by AFS does you no good if you have lost/reused/expired the tape 
containing the backup to that point.



You seem to be missing a #03.



># 04:
> "why is afs not updating ctime, mtime and atime in the filesystem and
> what needs to be done , to update this fields ..."
>
> What I've found:
> - there are 2 dates stored for a vnode:
>         - "ClientModTime" - modification time measured at the client side
>         - "ServerModTime" - modification time measured at the server side
>         ServerModTime is used only for partial dumps/releases.
>         ClientModTime is transmitted for all 3 types of times: ctime,
> mtime, atime         (it means you always get only the mtime)
> - possibilities:
> 	- updating "atime" is ambiguous/meaningless (multiple clients with
> cache, additional network load) 	- only ctime support could be implemented
> 		- I'm not sure, but maybe volume format change is needed, too (I'm
> still examining src/vol) 		- fileserver interface must be extended


In practice, the _real_ difference between ctime and mtime is that users 
are allowed to change the mtime of files they own (both in and out of AFS), 
and they are not allowed to change the ctime.  Would having the cache 
manager report the ServerModTime as the ctime meet your needs?  This could 
be done fairly trivially as a runtime configuration option in the client, 
without requiring any changes to the protocol or server.


-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA