Modify AFS clients and servers to support files bigger than 231-1 bytes. Here is the way [[JeffreyHutzelman]] [described](http://lists.openafs.org/pipermail/openafs-devel/2002-January/002304.html) the project: - Add a whole new set of fileserver RPC's that use 64-bit file sizes, offsets, and lengths. This would affect at least [[FetchData]], [[StoreData]], [[FetchStatus]], [[StoreStatus]], [[BulkStatus]], [[InlineBulkStatus]], and possibly some others. - Define semantics for large files, particularly in cases where clients try to manipulate them using the old RPC's. - Modify the fileserver backend to support large files. This may mean changing the vnode index format, among other things. - Modify the cache manager to implement the new RPC's, falling back on the old ones as appropriate. - Extend the volume dump format to support dumping files with >2GB of content. Backward compatibility is very important. Old clients must be able to talk to new fileservers and vice versa. It should be possible to move a volume containing no large files between new and old fileservers. It should be possible to perform a dump of a new volume, even if it contains large files, using an existing volume dump client. Remember also that AFS is a wire protocol with multiple implementors. Things like new RPC numbers and probably new volume dump tags should be coordinated. If you're really interested in working on this, I suggest coming up with a design proposal and asking for comments both here and on . ---- [[HartmutReuter]] responded in the same thread indicating that much of the client work has been done to support [[MultiResidentAFS]]. Doing the server part of the work is probably not as difficult. -- [[TedAnderson]] - 17 Jan 2002 This client-side work is available in the [[OpenAFSCVS]] tree and is expected to become available in the next series of stable releases after the 1.2 series. -- [[DerrickBrashear]] - 24 Jan 2002 I had a student working on this over the summer. [[HartmutReuter]] provided him with some further specifics: 1) The 1st problem is: where to store the high order 32 bits of the file length in the vnode. My suggestion is: Since we must use the NAMEI-interface for large file support, anyway, we can use the space currently occupied by vn\_ino\_hi. This is possible because with the NAMEI-interface the high order part of the inode-number is filled with the uniquifier which is already stored in the vnode, elsewhere. You just have to change the macros VN\_SET\_INO etc. and to make sure the field is cleared. (probably you cannot upgrade exisiting servers, but have to move the volumes to new servers.) 2) Use afs\_uint64 instead of afs\_uint32 for file sizes and offsets all over the code. The changes in stds.h show how to handle this on machines without the data type "long long", but I think you will use large file support only on modern systems which eather have native 64bit integers or have "long long". You must be carefull with the type conversion and casting, I had some strange experiences with it. 3) All library calls for I/O must be replaced by the 64-bit ones. Some times this is just a general -D during the compilation, sometimes the routines have different names. 4) Also the volserver must be able to transmit the high-order bits of the length. Instead of 'f' followed by the afs\_uint32 length of the file and the data we use 'h' followed by two afs\_uint32 numbers (the high order and low order 32 bits of the file size) followed by the data. Of course the old version must be understood for restore as well to allow the move of volumes from old servers to the new ones. 5) The salvager must be changed accordingly: byteCount in viceinode.h must become afs\_uint64 etc. I've picked up where my student left off, since we are very interested in having large file support. Since the CVS tree has been changing quite a bit lately, I've been working against the unstable 1.3.2 release. I've gotten much working, but not quite all the way yet. -- [[LindsayTodd]] - 06 Nov 2002