[OpenAFS-devel] Re: Yuck... largefile support really fouled things up bad...

[Hartmut Reuter]

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:  nneul@umr.edu
>> University of Missouri - Rolla         Phone: (573) 341-4841
>> Computing Services                       Fax: (573) 341-4216
>>
>>
>>  
>>
>>> -----Original Message-----
>>> From: Derrick J Brashear [mailto:shadow@dementia.org] 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 reuter@rzg.mpg.de
					   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)
-----------------------------------------------------------------