OpenAFS 1.4.4 client

# ./vos examine fs1-a
fs1-a                             2023883361 RW          3 K  On-line
    fs1.mitre.org /vicepa
    RWrite 2023883361 ROnly          0 Backup 2023883363
    MaxQuota       5000 K
    Creation    Wed Dec 31 19:00:00 1969
    Copy        Wed May 23 16:38:41 2007
    Backup      Wed May 23 23:25:09 2007
    Last Update Wed May 23 16:38:05 2007
    0 accesses in the past day (i.e., vnode references)

    RWrite: 2023883361    Backup: 2023883363
    number of sites -> 1
       server fs1.mitre.org partition /vicepa RW Site

Derrick J Brashear wrote:
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.

or

OpenAFS 1.4.2rc1 on RHELv3 SMP i686

or

OpenAFS 1.4.3 on RHELv4 uniprocessor i686

    Is your vos command built with any special options, such
    as "--disable-full-vos-listvol-switch" ???

No.

/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?

No.

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 2023883361) 05/23/2007 16:39:53 Scanning inodes on device /dev/rdsk/c3t6006016012341600D86B14C7E294DA11d0s0...
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?

No

Does touching a file in the volume change anything?

It updates the Last Update info properly.

_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info



_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Reply via email to