Eyal,
AFAIK, the following holds:
> 1) The kernel fully supports large files (64bit sizes)? This means the
> VFS probably.
Not fully. With Linux 2.1, file offsets are 64 bits internally. There
is also the llseek system call which allows to position files beyond
4GB. In theory, a read(2) could then be used to access data on such a
position.
In practice, many 2.1 file systems go through generic_file_read, which
silently truncates the file offset to 32 bits. Even if this was fixed,
it would be truncated shortly after that, because the readpage
interface does not support loff_t.
As for mapping large files: no way. First, mmap(2) does not support
passing large offsets. If it would, the page cache would truncate the
MS 32 bits. If the page cache would be large-file-aware, the file
systems would truncate.
Finally, we have stat(2): It does not support large files, either.
This is partially due to struct inode storing only 32 bits for the
file size. Same for file locking.
> 2) ext2fs supports large files?
No.
> 3) any other fs type?
Block devices do. They support at least more than 32 bits: It seems like
the block number must still fit into 32 bits. Given a minimum of 512
byte per block, this brings you well into the terabyte range.
As for 'real' file systems: I have not found any. Most don't support
large files on-disk. Those who do truncate the offset here or there.
The possible candidates are:
- NFS version 3 (is anybody working on this?)
- NTFS
- ufs (it supports large files since 4.4BSD, doesn't it)
Regards,
Martin