Jeff Blaine <[EMAIL PROTECTED]> 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
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
