[OpenAFS] Volume creation and update time change in 1.4.1-rc10?

[Jeffrey Hutzelman]

On Friday, March 24, 2006 08:04:42 PM -0800 Russ Allbery <rra@stanford.edu> 
wrote:

> We moved a pre-existing test volume from another server onto a 1.4.1-rc10
> server earlier this week, and now vos examine output shows zeroed
> timestamps for volume creation and last update:
>
> user.wjt                         2003745036 RW      41293 K  On-line
>     afssvr13.Stanford.EDU /vicepa
>     RWrite 2003745036 ROnly          0 Backup 2003745038
>     MaxQuota     215000 K
>     Creation    Wed Dec 31 16:00:00 1969
>     Copy        Tue Mar 21 16:55:57 2006
>     Backup      Fri Mar 24 02:15:01 2006
>     Last Update Never
>
>     RWrite: 2003745036    Backup: 2003745038
>     number of sites -> 1
>        server afssvr13.Stanford.EDU partition /vicepa RW Site
>
> The same output shows up in vos listvol -long.
>
> In Zephyr conversation, Derrick thought this may have been due to an
> intentional change.  I'd like to understand more about this and whether we
> can prevent it from happening somehow.  We have fairly extensive AFS
> reports that rely, among other things, on those values to determine who is
> actually using their AFS space and how recently they've used it, and we
> need those values to be preserved across volume moves.
>
> Note that this isn't a case, so far as I can tell, of simple latency in
> updating that information.  The volume was moved onto that server three
> days ago.

Hm.  This might be the result of an interation between the way vos decides 
what values to print and a change in how moves work.  In particular, the 
zero creation time disturbs me somewhat.

Unfortunately, vos lies sometimes and doesn't always tell you what values 
are really in some of those fields, so they can be a bit useless for 
debugging.

Try examining that volume with -format to see the real values.

I bet you'll find that if you move a volume to one of your existing 
servers, immediately after the move a normal vos examine will report the 
same values for create, copy, and modify dates, but using -format will show 
that the modify date is actually zero.  Moving a volume to the new server 
is probably resulting in both the create and modify dates being set to 
zero, though I haven't yet determined why that is happening.

-- Jeff