[OpenAFS-devel] OPenAFS-1.3.74 on SOlaris 9 - all files are zero

[Douglas E. Engert]

More on large file support using a 32 bit SOlaris kernel.
Here is a problem with the 32 bit kernel but not nessesarily the problem
of zero data.  Offsets are limited to 32 bits by the header files:

On a 32 bit code On Solaris /usr/include/sys/param.h has:

    212  #define btodb(bytes)            /* calculates (bytes / DEV_BSIZE) */ \
    213      ((unsigned long)(bytes) >> DEV_BSHIFT)
    214  #define dbtob(db)           /* calculates (db * DEV_BSIZE) */ \
    215      ((unsigned long)(db) << DEV_BSHIFT)
    216
    217  /*  64 bit versions of btodb and dbtob */
    218  #define lbtodb(bytes)           /* calculates (bytes / DEV_BSIZE) */ \
    219      ((offset_t)(bytes) >> DEV_BSHIFT)
    220  #define ldbtob(db)          /* calculates (db * DEV_BSIZE) */ \
    221      ((offset_t)(db) << DEV_BSHIFT)

Note the typecast in the dbtob to a long. This will force 32 bit results
on a 32 bit kernel. AFS uses this macro all over the place in in libafs.
It looks like it should use the ldbtob instead. But only Solaris has the
ldbtob. Its not clear the best way to fix this.

Not only this, but the /usr/include/sys/buf.h ends up with has:
#define b_blkno _b_blkno._p._l
which is a 32 bit number. AFS uses adp->b_blkno in a lot of places.
rather the adp->b_lblkno which would be 64.

As an example of this: In afs_vnop_strategy.c:83
tuio.afsio_offset = (afs_offs_t) dbtob)adp->blkno);

in MODLOAD32
the precompiler passes this to the compiler where _l is 32 bits:

tuio. _uio_offset . _p . _l = (afs_offs_t)  ( ( unsigned long )
( abp -> _b_blkno . _p . _l ) << 9 );

Note only 32 bits are copied, and long is 32 bits.

Where as on MODLOAD64 it ends up doing the 64 bit versions
where _f is 64 bits:

  tuio. _uio_offset . _f = (afs_offs_t)  ( ( unsigned long )
( abp ->_b_blkno . _f ) << 9 );

So that would be a lot of changes to get the SOlaris 32 bit
cachemanager to support large files.

You may want to only define the AFS_64_BIT_CLIENT on 64 bit machines.


Derrick J Brashear wrote:

> On Fri, 12 Nov 2004, Douglas E. Engert wrote:
> 
>>> solaris-largefile-client-20040808
>>>
>>> "#define AFS_64BIT_CLIENT       1"
>>>
>>> maybe it should be disabled for older (32 bit) solaris until we find 
>>> out what the problem is.
>>
>>
>> Yes that makes a difference. It looks like it works without
>> the define. Will look some more on Monday.
>>
> 
> i bet some variable ends up being a 32bit type that shouldn't, that only 
> hits the ufs dcache code
> 
>>
>> P.S. the with a memcache works either way.
> 
> 
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444