On Monday, February 21, 2005 01:57:20 PM +0100 Peter Somogyi <[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA
_______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
