[OpenAFS] Volume Creation Date Nonsense
Derrick J Brashear
Wed, 23 May 2007 16:57:43 -0400 (EDT)
It's going to be a volser bug or race at create time. There's no reason
anything else should fix it other than actually fixing the relevant code.
I looked at the code cursorily over the weekend but haven't gotten further
yet as work-work has taken precedence.
On Wed, 23 May 2007, Jeff Blaine wrote:
>>> 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.
>> /1/ what openafs version, os version, & CPU architecture
>> machine is your "vos" command?
> IBM AFS 3.6 patch ... something from last year on Solaris 9
> SPARC (sun4u) 64-bit mode.
> OpenAFS 1.4.2rc1 on RHELv3 SMP i686
> OpenAFS 1.4.3 on RHELv4 uniprocessor i686
>> 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.
> OpenAFS 1.4.2 on Solaris 9 SPARC (sun4u) 64-bit mode
> And "No"
>> 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?
> We *may* have a 1.4.4 RHELv5 box. I'll look.
>> does "bos salvage fs1 fs1-a" fix this problem?
>> does "bos salvage fs1 -a" fix this problem?
> I'm not in a position to do that.
>> Do either report anything in SalvageLog?
> The former reports:
> @(#) OpenAFS 1.4.2 built 2006-12-05
> 05/23/2007 16:39:43 STARTING AFS SALVAGER 2.4 (/usr/afs/bin/salvager /vicepa
> 05/23/2007 16:39:53 Scanning inodes on device
> 05/23/2007 16:40:41 1 nVolumesInInodeFile 28
> 05/23/2007 16:40:42 SALVAGING VOLUME 2023883361.
> 05/23/2007 16:40:42 fs1-a (2023883361) updated 05/23/2007 16:38
> 05/23/2007 16:40:42 totalInodes 5
> 05/23/2007 16:40:42 Salvaged fs1-a (2023883361): 2 files, 3 blocks
>> Does moving the volume to another server change anything?
>> Does touching a file in the volume change anything?
> It updates the Last Update info properly.
> OpenAFS-info mailing list