Sorry for my late reply, but I broke my leg and was in the hospital for some days.
The point is:
1.) You can have large file support only with the namei-interface.
2.) the namei-interface needs AFS_64BIT_IOPS_ENV to be set because the inode number used in namei_ops.c is 64 bit long.
3.) the field vn_ino_hi used to store redundantly the same contents as the field uniqifier. Therefore I thought it would be better to modify VNDISK_GET_INO and VNDISK_SET_INO in order to use immediatly uniquifier and to use vn_ino_hi for the high order 32 bits of the file length.
4.) You never will be able to change an old fileserver to a large file supporting fileserver by just installing the new binaries. You will have to move the volumes to the new server. During the move process the old contents ov vn_ino_hi is not transfered and the field is cleared.
Hartmut
R. Lindsay Todd schrieb:
I can live with this change, and certainly agree that it is better to make this change now than later.
/Lindsay
Neulinger, Nathan wrote:
How do y'all feel about maintaining on-disk compatability with adding the largefile fileserver support to openafs? There are some issues with the current trunk code that make assumptions that are not correct (such as any 64bit_env build MUST HAVE largefile_env defined, or it doesn't work right). Also assumes that we will never be able to do both 64bit iops and large files in the same binary.
I'd like to use to reserved6 field in the vnode disk structure to add a length_hi, and start with the attached patch, plus other sanity checking code will need added. Since this code hasn't ever been in a real release of openafs, now is the time to decide how to do it. Current implementation forces some dead ends, seems like using the reserved slot is the way to go. Derrick wanted me to talk to both of you first before he started applying these changes. He did apply one I sent that at least gets rid of the failure I talked about on -devel yesterday. Do either of you object to using reserved6 as length_hi, and eliminating the field re-use that is currently in place?
-- Nathan
------------------------------------------------------------ Nathan Neulinger EMail: [EMAIL PROTECTED] University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216
-----Original Message-----
From: Derrick J Brashear [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 12:54 PM
To: Neulinger, Nathan
Subject: RE: Yuck... largefile support really fouled things up bad...
On Thu, 13 Mar 2003, Neulinger, Nathan wrote:
If largefile_env is defined, it forces namei.
that doesn't conflict with my statement.
largefile_env is currently incompatible with 64bit_iops
(it's reusing
vn_ino_hi, which iops uses), but the only reason it doesn't
clash/fail
is that it is forcing namei.
ok, so talk to lindsay or hartmut and see if they care if we switch.
--
-----------------------------------------------------------------
Hartmut Reuter e-mail [EMAIL PROTECTED]
phone +49-89-3299-1328
RZG (Rechenzentrum Garching) fax +49-89-3299-1301
Computing Center of the Max-Planck-Gesellschaft (MPG) and the
Institut fuer Plasmaphysik (IPP)
-----------------------------------------------------------------_______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
