e33605e631ddb56d5a4af53997fb8a01b8e69a29
[openafs-wiki.git] / AFSLore / LargeFiles.mdwn
1 Modify AFS clients and servers to support files bigger than 2<sup>31</sup>-1 bytes.
2
3 Here is the way [[JeffreyHutzelman]] [described](http://lists.openafs.org/pipermail/openafs-devel/2002-January/002304.html) the project:
4
5 - 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.
6
7 - Define semantics for large files, particularly in cases where clients try to manipulate them using the old RPC's.
8
9 - Modify the fileserver backend to support large files. This may mean changing the vnode index format, among other things.
10
11 - Modify the cache manager to implement the new RPC's, falling back on the old ones as appropriate.
12
13 - Extend the volume dump format to support dumping files with &gt;2GB of content.
14
15 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.
16
17 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 <arla-drinkers@stacken.kth.se>.
18
19 ----
20
21 [[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.
22
23 -- [[TedAnderson]] - 17 Jan 2002