[OpenAFS-devel] OPenAFS-1.3.74 on Solaris 9 - Suggestion to tune off large file client
support on 32 bit kernels
Douglas E. Engert
deengert@anl.gov
Thu, 18 Nov 2004 09:12:41 -0600
Here is a suggested changed to 1.3.74 to turn on the large file client support
only on 64 bit Solaris kernels. Similar changes to the other sun4x_* are also
recommended.
-- ./src/config/,param.sun4x_59.h Sun Aug 8 13:14:08 2004
+++ ./src/config/param.sun4x_59.h Tue Nov 16 10:57:26 2004
@@ -22,7 +22,13 @@
#define AFS_SUN59_ENV 1
#define AFS_64BIT_ENV 1 /* Defines afs_int32 as int, not long. */
+/*
+ * Only define on 64 bit kernel, untill problems with 32 bit
+ * and large file support are resolved
+ */
+#if defined(__sparcv9)
#define AFS_64BIT_CLIENT 1
+#endif
#define AFS_HAVE_FLOCK_SYSID 1
(There is already a similar test using __sparcv9 in the header file.)
Although it would be possible to support large files in the 32 bit kernel,
the effort needed to change the code may be substantial. All the newer
Solaris machines support 64 bit kernels, and even if some one had an older
machine, it would most likely be small, and not able to handle large files
anyway.
Following is a reprint of the previous note outlining what would need to
be changed if someone wanted to pursue the support in a 32 bit kernel.
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
_______________________________________________
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-devel