16069e1349
A number of fileserver RPC operations return a VolSync record as part of their reply that gives some information about the state of the volume being accessed, including: (1) A volume Creation timestamp. For an RW volume, this is the time at which the volume was created; if it changes, the RW volume was presumably restored from a backup and all cached data should be scrubbed as Data Version numbers could regress on the files in the volume. For an RO volume, this is the time it was last snapshotted from the RW volume. It is expected to advance each time this happens; if it regresses, cached data should be scrubbed. (2) A volume Update timestamp (Auristor only). For an RW volume, this is updated any time any change is made to a volume or its contents. If it regresses, all cached data must be scrubbed. For an RO volume, this is a copy of the RW volume's Update timestamp at the point of snapshotting. It can be used as a version number when checking to see if a callback on a RO volume was due to a snapshot. If it regresses, all cached data must be scrubbed. but this is currently not made use of by the in-kernel afs filesystem. Make the afs filesystem use this by: (1) Add an update time field to the afs_volsync struct and use a value of TIME64_MIN in both that and the creation time to indicate that they are unset. (2) Add creation and update time fields to the afs_volume struct and use this to track the two timestamps. (3) Add a volsync_lock mutex to the afs_volume struct to control modification access for when we detect a change in these values. (3) Add a 'pre-op volsync' struct to the afs_operation struct to record the state of the volume tracking before the op. (4) Add a new counter, cb_scrub, to the afs_volume struct to count events that require all data to be scrubbed. A copy is placed in the afs_vnode struct (inode) and if they no longer match, a scrub takes place. (5) When the result of an operation is being parsed, parse the VolSync data too, if it is provided. Note that the two timestamps are handled separately, since they don't work in quite the same way. - If the afs_volume tracking is unset, just set it and do nothing else. - If the result timestamps are the same as the ones in afs_volume, do nothing. - If the timestamps regress, increment cb_scrub if not already done so. - If the creation timestamp on a RW volume changes, increment cb_scrub if not already done so. - If the creation timestamp on a RO volume advances, update the server list and see if the current server has been excluded, if so reissue the op. Once over half of the replication sites have been updated, increment cb_ro_snapshot to indicate updates may be required and switch over to excluding unupdated replication sites. - If the creation timestamp on a Backup volume advances, just increment cb_ro_snapshot to trigger updates. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org |
||
---|---|---|
.. | ||
addr_list.c | ||
addr_prefs.c | ||
afs_cm.h | ||
afs_fs.h | ||
afs_vl.h | ||
afs.h | ||
callback.c | ||
cell.c | ||
cmservice.c | ||
dir_edit.c | ||
dir_silly.c | ||
dir.c | ||
dynroot.c | ||
file.c | ||
flock.c | ||
fs_operation.c | ||
fs_probe.c | ||
fsclient.c | ||
inode.c | ||
internal.h | ||
Kconfig | ||
main.c | ||
Makefile | ||
misc.c | ||
mntpt.c | ||
proc.c | ||
protocol_afs.h | ||
protocol_uae.h | ||
protocol_yfs.h | ||
rotate.c | ||
rxrpc.c | ||
security.c | ||
server_list.c | ||
server.c | ||
super.c | ||
validation.c | ||
vl_alias.c | ||
vl_list.c | ||
vl_probe.c | ||
vl_rotate.c | ||
vlclient.c | ||
volume.c | ||
write.c | ||
xattr.c | ||
xdr_fs.h | ||
yfsclient.c |