[OpenAFS] Volume Creation Date Nonsense

[Marcus Watts]

Jeff Blaine <jblaine@mitre.org> writes:
>  > No solution, but we see the same - apparently transarc
>  > afs had a problem and all volumes created in that period
>  > all have the epoch as their create time.
> 
> Well, that's not what we're seeing.
> 
> Any volume we create *today* on our OpenAFS servers has
> the UNIX epoch as the create date.
> 
> Our entire cell is time-synched fine.
> 
> Performing the 'vos create' from an IBM AFS client or OpenAFS
> client makes no difference.
> 
> bash-3.2$ vos create fs1 a fs1-a
> Volume 2023883358 created on partition /vicepa of fs1
> bash-3.2$ vos examine fs1-a
> fs1-a                             2023883358 RW          2 K  On-line
>      fs1.mitre.org /vicepa
>      RWrite 2023883358 ROnly          0 Backup          0
>      MaxQuota       5000 K
>      Creation    Wed Dec 31 19:00:00 1969
>      Last Update Wed Dec 31 19:00:00 1969
>      0 accesses in the past day (i.e., vnode references)
> 
>      RWrite: 2023883358
>      number of sites -> 1
>         server fs1.mitre.org partition /vicepa RW Site

Ok, that's interesting.

In the 1.4.4 openafs source I see; "Last Update" should never
appear as "Wed Dec 31 19:00:00 1969".  A "0" date should instead
appear as "Never".  However, "Creation" doesn't haev a check
for a 0 date and will show up that way.

My attempt to replicate your behavior failed; my newly minted volume
on a test server went offline instantly.  This is intensely interesting
to me, but it is hopefully not related to your problem.

So here's some questions that might help:

/1/ what openafs version, os version, & CPU architecture
	machine is your "vos" command?
	Is your vos command built with any special options, such
	as "--disable-full-vos-listvol-switch" ???
/2/ what openafs version, os version, & CPU architecture is
	your fileserver?
	Is your fileserver built with any special options, such
	as "--enable-fast-restart", "--enable-namei-fileserver", etc.?
normally I'd also ask about your db servers, but I don't think that's
related to this problem.

Also some experiments:
does running "vos examine" on a client machine with the
	opposite byte sex change anything?
does running the "vos" commands (and creating a new volume) from
	a client running the 'latest generation' of openafs change anything?
does "bos salvage fs1 fs1-a" fix this problem?
does "bos salvage fs1 -a" fix this problem?
Do either report anything in SalvageLog?
Does moving the volume to another server change anything?
Does touching a file in the volume change anything?

				-Marcus Watts